[jeromeyyy]

See #4007

Problem

release_unlocked_production (via promote_package_version) queries every dependency's SubscriberPackageVersion with the target package's install_key in the InstallationKey filter. As reported in #4007, when a dependency unlocked package does not share that key, the Tooling API rejects the query with INSTALL_KEY_INVALID and the release fails.

What this changes (and what it does not)

Dependency SubscriberPackageVersion queries now retry once without the InstallationKey filter when the configured key is rejected with INSTALL_KEY_INVALID.

• Proposed handling, not a proven fix: dependencies that are not key-protected. The Tooling API only requires the InstallationKey filter when the queried version is itself protected by a key, so a keyless retry should let the release proceed in that case. However, the issue report involves a differently-keyed dependency, and there is no live-org or documented evidence here that a non-key-protected version rejects a mismatched key filter with INSTALL_KEY_INVALID - so this path is proposed behavior that needs maintainer qualification, not an established defect fix.
• Not fixed: dependencies protected by their own, different install key (the reported scenario). A keyless query cannot retrieve a key-protected version. If the retry fails, its original API error is preserved, including its error code and response. This task does not currently provide a separate dependency key. No promotion or other workaround is claimed here. Full resolution of release_unlocked_production fails when dependent unlocked package has an install key #4007 remains open and requires maintainer guidance.

Only a structured error response containing the exact errorCode value INSTALL_KEY_INVALID triggers the retry. Unrelated API errors, malformed error payloads, and failures on the target-package path propagate unchanged.

Queries for the target package itself are unchanged: its configured key is still used, and a rejection still fails the task.

Tests

• 26 tests in the task module pass. Coverage includes the proposed successful fallback using mocked responses, no records from the retry, a second API rejection, exact structured error-code matching, unrelated errors before and after retry, no configured key, and fail-closed target-package queries.
• Seven corrected/new cases fail against the prior PR code and pass after the error-handling repair. These mocks verify local control flow, not Salesforce behavior for unprotected dependency versions.
• Full local suite: 3289 passed, 37 skipped, 5 pre-existing environment failures (4 OAuth client tests and test_bad_entry_point). No live Salesforce org was used.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @jeromeyyy to sign the Salesforce Inc. Contributor License Agreement.