Add resumable connect lifecycle framework

[Surendra Goutham (is-goutham)]

Summary

Adds a reusable integration lifecycle framework and uses Workday as its first provider:

• declarative provider contracts with ordered validation phases
• live re-verification when resuming saved progress
• role-gated mutation with checkpointed rollback
• per-agent lifecycle state
• package-gated routing for already-installed CEA Workday integrations
• explicit protection preventing Declarative Agents from entering the CEA lifecycle

This is replacement PR 3 of the PR #290 split and is stacked on #301.

Validation

• python -m pytest tests/setup/test_connect_lifecycle.py tests/setup/test_setup_router.py tests/scripts/test_checkpoint.py tests/flightcheck/test_cli_single_checkpoint.py -q — 34 passed
• git diff --check

[nkemms]

MAJOR: The new Workday lifecycle runner depends on CLI plumbing that does not exist in scripts/flightcheck/cli.py, so the connect flow cannot execute as written.

1. solutions/ess-maker-skills/src/skills/connect/shared/lifecycle-runner.md:34-37 and :186-188 instruct callers to pass --connect-config and --agent-slug, but scripts/flightcheck/cli.py:1046-1138 only defines --scope, --checkpoint, --environment-url, --workday-app-id, --servicenow-connection, --select-targets, etc. There is no parser support for either flag, so the generated checkpoint commands will fail before WD-REST-001 / WD-REST-002 can run.

2. solutions/ess-maker-skills/src/skills/connect/shared/lifecycle-contract-schema.md:52-64 says provider state lives in connectConfig, but scripts/flightcheck/cli.py:733-739,908-910 only loads .local/config.json into
   unner.config. The new Workday checks read
   unner.config, so without a real connect-config plumbing path they will keep looking at the wrong file and report false NotConfigured / Failed results.

[Surendra Goutham (is-goutham)]

The requested plumbing is present in this PR's updated base (#301) and is now propagated into this branch. cli.py defines both --connect-config and --agent-slug; _merge_connect_config overlays the provider JSON and stamps _connectConfigPath; _run_single_checkpoint assigns the selected slug to the runner. tests/flightcheck/test_cli_single_checkpoint.py pins the explicit slug, overlay data, and marker. No additional lifecycle-runner change is needed.

[nkemms]

Updated review findings — merge blockers remain

• Major — selected-agent validation still scans other agents. WD-REST-002 does not consistently constrain its result to runner.agent_slug, so another agent in the workspace can determine whether the selected-agent lifecycle passes or fails. Resolve and validate only the explicitly selected agent.
• Major — action and verification disagree about the installed topic identity. The action discovers the actual installed Workday user-context dialog because package names can vary, while WD-REST-002 hardcodes WorkdaySystemGetUserContextV2. A correctly wired package with another installed identity can be rejected. Pass the discovered identity into verification or have the check resolve the same authoritative installed component.
• Minor — connectConfig is documented at the wrong schema level. The schema describes it as phase state while the runner and contract consume it as a top-level field. Align the schema with the executable contract.

[nkemms]

Re-reviewed the current head (17c8d8e) against its stacked base. The lifecycle still has selected-identity and state-contract blockers:

• Connected state is not reliably scoped to the selected agent — solutions/ess-maker-skills/src/skills/connect/step1.md:14-18 accepts shared Workday setup state as sufficient, while scripts/flightcheck/checks/workday_extension.py:573-619 can pass WD-REST-002 from any agent topic. A configured sibling can therefore make the selected agent look connected.
• The wiring action resolves the installed topic from the wrong tree — src/skills/connect/workday/actions/wire-user-context-redirect.md:33-46 searches workspace/agents/{AGENT_SLUG}/topics, while the established setup flow resolves installed dialog IDs from .local/agents/{AGENT_SLUG}/topics and edits the workspace user-context topic separately.
• Cancel can be persisted as applied — src/skills/connect/shared/lifecycle-runner.md:174-176 unconditionally writes actionApplied = true after the action fragment returns, but wire-user-context-redirect.md:93-101 permits “Not now” without publishing. Return an explicit applied/cancelled result and persist true only after observed publication.
• Completion copy overclaims non-passing outcomes — lifecycle-runner.md:248-251 says all required phases “passed,” although the schema permits acknowledged Manual, Warning, Skipped, and NotConfigured completion. Report “completed” with the actual result classes instead.

Also update src/skills/connect/workday/SKILL.md:3-7, which still promises a setup-orchestrator fallback that step1.md no longer performs.

[Surendra Goutham (is-goutham)]

Addressed the latest blockers in 0af31a7: connected state and WD-REST-002 are selected-agent scoped, installed dialog identity is resolved from .local/agents while the editable topic remains under workspace, cancellation cannot set actionApplied, and completion reports actual result classes. Validation: 813 targeted tests passed.

[nkemms]

Re-reviewed the latest head (0af31a7). The selected-agent connection state, installed-topic lookup, cancellation result, completion wording, and stale routing contract have been corrected.

I found no remaining critical blocker. Good to merge.

The base branch was changed.

[Surendra Goutham (is-goutham)]

PR #301 is merged. This PR is retargeted to main, synchronized with the current base, and validated: 855 lifecycle/FlightCheck tests passed. Re-review requested for the current head.