Audit ServiceTypeByKey — add Ignored entries for newer Apple entitlements

[Badlazzor]

Stacked on #325 (fix/healthkit-access-entitlement). Merge that one first; then this PR's diff collapses to its own three entries.

Issue

Any iOS/macOS entitlement key that is not present in ServiceTypeByKey (autocodesign/devportalclient/appstoreconnect/capabilities.go) causes autocodesign.Entitlement.Capability() to return:

unknown entitlement key: <key>

That error propagates up through ProfileClient.SyncBundleID → autocodesign/profiles.go#ensureBundleID and aborts the entire automatic-code-signing phase with:

failed to manage code signing: failed to ensure code signing assets:
failed to ensure profiles: failed to update bundle ID capabilities:
unknown entitlement key: <key>

The map currently has 34 entries. Apple has added a number of entitlement keys since it was last extended (see current entitlements reference), and each such addition is a latent production break the moment a user project declares that key. #325 is the most recently reported instance (com.apple.developer.healthkit.access, iOS 17.5+).

Intent

Audit ServiceTypeByKey for entitlement keys that should be safely mapped to Ignored because they do not require App Store Connect registration (matching the existing treatment of e.g. com.apple.developer.icloud-container-identifiers). Flag keys that likely need a real CapabilityType mapping for maintainer review in a follow-up.

Changes

Three new Ignored entries — build/runtime entitlements, not App Store Connect-registrable:

Key	Apple doc	Why Ignored
com.apple.developer.kernel.extended-virtual-addressing	link	Build-time memory entitlement; no ASC capability
com.apple.developer.kernel.increased-memory-limit	link	Build-time memory entitlement; no ASC capability
com.apple.developer.authentication-services.credential-provider-ui	link	UI-hook companion to the already-mapped AutofillCredentialProvider capability; metadata-only

Plus a table-driven regression test (TestCapability_IgnoredKeys) covering both Capability() and AppearsOnDeveloperPortal() for each new key.

Intentionally out of scope

Flagging for maintainer decision — these likely need a real CapabilityType, not Ignored:

• com.apple.developer.weatherkit — WeatherKit is a registrable service (appears under Services → WeatherKit in App Store Connect). Needs a new CapabilityType constant (e.g. WeatherKit) and a decision on whether the step should auto-register it.
• com.apple.developer.matter.allow-setup-payload — Matter companion entitlement for HomePod/Apple TV setup payloads; ASC registration requirements unclear from public docs. Worth checking against the ASC API before classifying.

Anything else currently missing from the map that you'd like folded in here, happy to add — just flagging in review.

Follow-up

There is also a structural hardening worth considering — making Capability() warn-and-skip on unknown keys rather than hard-erroring — so a fresh Apple entitlement does not break every affected build until the allow-list catches up. Proposing that as a separate stacked PR after this one.

Test plan

• go test ./autocodesign/...
• go vet ./autocodesign/...
• New TestCapability_IgnoredKeys passes for all three keys
• Integration: build a target declaring kernel.increased-memory-limit via xcode-archive@6.x after dep bump; confirm no unknown entitlement key error

🤖 Generated with Claude Code

[benbitrise]

I wasn't able to log in to the Developer Portal because our legal agreement is out of date, but are you sure Healthkit can be ignored? See: https://developer.apple.com/documentation/Xcode/adding-capabilities-to-your-app#Perform-additional-configuration-steps

[Badlazzor]

Good check. Ben — the ASC-registrable capability is com.apple.developer.healthkit (line 60, already mapped to Healthkit). The .access subkey is a build/runtime array declaring which HealthKit data classes (e.g. health-records) the app accesses; the ASC registration itself sits on the parent key. That's why Apple's doc you linked flags additional configuration for the capability parent, not the .access subkey.

That entry actually came in on #325 (already merged); it's showing in this PR's context lines around the new adds. Happy to file a follow-up if you'd prefer the .access variant treated as its own ASC-registrable capability, but I don't see evidence in the ASC docs/portal that it is.