CEXT-6834: Plan again on every upgrade request

[iivvaannxx]

Description

First PR of the CEXT-6834 stack. It changes when the lifecycle plans and stops the upgrade engine from reusing plans. The domains themselves move to live-state planning in the PRs above this one (#717 for webhooks, events next).

• Revert of CEXT-6770: Fix orphaned subscriptions after a failed auto upgrade #705 (CEXT-6770). CEXT-6770: Fix orphaned subscriptions after a failed auto upgrade #705 made a failed attempt advance the baseline, so the next plan would see what the failed attempt had created. Once a domain plans from live state, it reads those resources from Commerce and I/O Events directly. The baseline goes back to meaning "the last successful upgrade".
• A retry plans again. resumeFailedAttempt is removed. Resuming reused the failed attempt's plan, whose before values no longer match what exists after a partial apply.
• No plan reuse. findReusablePlan and the skipped result are removed. Every plan request plans again and replaces pendingPlan.
• PlanningInput.failedAttempt. When the latest attempt failed, each domain receives that attempt's target config and its own plan for that attempt. Webhooks use it in CEXT-6834: Plan webhook upgrades from live state #717 to remember which values a config of ours set, for fields the new config leaves out.
• ResourceOperation.reason. Every operation is labeled change or drift, so the UI can hide drift. change means the target config caused the operation. drift means the baseline and target agree, but the deployed state doesn't match them. Domains that still plan from the baseline only produce change.
• docs/usage.md and the migration skill's executor.md now say resources are "created" instead of "created or reused".

Admin UI and custom installation still plan from the baseline. Custom installation scripts can run again after a failed attempt; that is tracked in CEXT-6814.

Related Issue

https://jira.corp.adobe.com/browse/CEXT-6834

Motivation and Context

An upgrade that failed partway, or that ran a plan computed before something changed, could finish as "succeeded" while Commerce no longer matched the target config. Planning again from the current state on every request is the base the domain changes build on.

Merge this stack as a whole. Until the events PR lands, events lose the coverage #705 gave them.

How Has This Been Tested?

pnpm --filter @adobe/aio-commerce-lib-app test: 1332 passing on this branch. Existing operation fixtures and expectations now carry reason. The runtime.test.ts and installation.test.ts cases now assert that a retry plans again and that a pending plan is replaced, not reused. pnpm typecheck and Biome are clean.

Screenshots (if appropriate):

Not applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have read the DEVELOPMENT document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5228644

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@adobe/aio-commerce-lib-app	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR