feat(ipsec-xfrm): supervise cancellation-safe single-object installs

[VerifiedOrganic]

Problem

PR #403 adds a cancellation-safe staged journal for the SA-plus-policy composite. Consumers also have legitimate single-object XFRM install operations:

• an SA-only install when a new SA intentionally reuses an existing shared policy; and
• an additional policy-only install when one SA requires more than one policy direction.

Calling XfrmBackend::install_sa or install_policy directly inside a cancellable consumer future preserves the same ambiguity addressed by #402: after issue but before the result is observed, the consumer cannot know whether it owns an applied object. Pre-registering intent as cleanup authority can delete a pre-existing object after AlreadyExists; registering only after success can leak an acquired object on cancellation.

XfrmStagedInstall cannot safely represent either operation without inventing a duplicate or dummy companion mutation. Consumers must not infer kernel ownership from call order or process-local intent.

Requested SDK boundary

Provide an additive cancellation-safe staged boundary for exact SA-only and policy-only installs, or generalize the landed journal so one typed operation can be supervised independently.

The boundary should preserve the properties of PR #403:

• affine one-run execution with caller-retained journal state;
• owned worker supervision after first poll;
• explicit issued, acknowledged, rejected, indeterminate, committed, recovered, and supervision-lost states;
• generation-bound classified recovery under caller-held writer exclusion;
• exact object identity without broadened deletion authority; and
• redaction-safe outcome, error, and debug surfaces.

Acceptance tests

• Dropping an unpolled staged SA-only or policy-only install performs no mutation.
• Dropping the observer after issue leaves the owned worker and claim live until the backend result is observed.
• AlreadyExists authorizes no removal of the pre-existing object.
• Acknowledged acquisition can be committed to product ownership.
• StateIndeterminate requires explicit classified readback before recovery.
• Recovery removes only an exact object classified as owned; Absent and Foreign never trigger deletion.
• Dropping recovery does not release the claim while removal remains live.
• Runtime or worker loss permanently blocks in-process commit/recovery until a fresh process re-establishes exclusion and readback.
• All public formatting remains free of keys, addresses, selectors, and SPIs.

Context

Observed against SDK main at 4c70b1fedd4d26e7c5e181f57a64e4048957abce. This is a generic operation-ownership gap and contains no subscriber, endpoint, key, SPI, credential, or production-network value.

[VerifiedOrganic]

Implementation is now in progress in an isolated worktree. The scope is limited to generalizing the landed staged ownership/supervision contract for exact SA-only and policy-only installs; no parallel recovery framework or unrelated XFRM expansion will be introduced. The issue will not be marked ready for review until the exact candidate passes local validation and independent adversarial review.

[VerifiedOrganic]

Adversarial review: first-poll claim is not visible in public journal state

The current candidate has a scheduling window after XfrmStagedSingleInstall::run is first polled:

1. RunGuard::begin sets the private lifecycle to Running.
2. run spawns the owned worker and waits on its JoinHandle.
3. Before the worker first polls run_inner, neither sa_possible/policy_possible nor runner_inflight is set.
4. During that window, public journal.ownership() reports NotStarted, recovery_plan() is empty, and ownership().has_residue() is false, although the scheduled owned worker can subsequently issue the mutation after the observer is dropped.

commit() and recover() still fail closed with RunnerNotFinished, so this is not an SDK-internal blind-delete path. It is nevertheless a consumer hazard: a supervisor using the public read-only journal state as its retirement predicate can discard the only retained claim while a first-polled worker remains live.

Required invariant: once run has been first-polled and scheduled, public journal state must remain visibly non-terminal until the owned worker records a definitive rejection/rollback or a completed acquisition. A safe implementation can set the exact candidate and runner_inflight atomically before spawn; this does not grant cleanup authority because recovery remains rejected while lifecycle is Running, definitive AlreadyExists clears the candidate before finish, and abnormal worker loss permanently blocks in-process recovery. A dedicated Scheduled/InFlight state with equivalent semantics is also acceptable.

Please add a deterministic hostile regression that manually polls run exactly once on a current-thread runtime, before the spawned worker can first poll, then drops the observer. Assert that (a) the journal exposes the exact live claim and has_residue=true, (b) recovery is rejected as RunnerNotFinished while the worker is live, (c) the detached owned worker still reaches the backend, and (d) a definitive AlreadyExists clears the candidate without any removal. Cover both single-object constructors; the shared composite runner should retain the same invariant.

Fix feasibility: premarking before spawn is sound if it is a non-recoverable in-flight claim. Set scope-specific *_possible=true and runner_inflight=InstallSa/InstallPolicy in RunGuard::begin (or a new begin helper), then remove or idempotently retain the duplicate run_inner transition. If spawn/task never begins, captured guard Drop records SupervisionLost; no same-process classified recovery is allowed, so the conservative candidate cannot delete a pre-existing object. try_current() should remain before the premark so RuntimeUnavailable remains a proven no-mutation empty journal.

[VerifiedOrganic]

Recovery classification gap: no exact policy readback

The candidate exposes ExactQuerySaRequest / query_sa_exact, but XfrmBackend still has no exact policy query. That leaves a policy-only/FWD install with an indeterminate backend result impossible to classify as Owned, Absent, or Foreign through SDK primitives.

The exact policy identity retained by recovery_plan().policy_exact() is mutation intent, not readback evidence, so a consumer must not convert it into cleanup authority. Normal acknowledged policy installs can commit and definitive rejections can clear their candidate, but an indeterminate result, observer loss, or ambiguous recovery must remain fail-closed unless the caller has a separate authoritative exact policy readback under the same namespace-wide writer exclusion.

Please either add a typed query_policy_exact boundary with enough kernel identity to distinguish exact absence/match/mismatch, plus mock/Linux hostile tests, or explicitly make policy recovery after indeterminate outcomes unsupported in the public contract. The product cannot honestly claim classified single-policy recovery otherwise.

[VerifiedOrganic]

Ownership classification also requires pre-state evidence

Exact post-read is necessary but is not sufficient after an indeterminate CREATE|EXCL install. An identical SA or policy may have pre-existed, with the negative EEXIST acknowledgement being the result that was lost. In that case, a matching post-read cannot establish that this runner owns the object.

A consumer can classify Owned only while holding the namespace-wide writer fence continuously and with one of:

• authoritative product ownership metadata, or
• exact preflight Absent evidence before the first mutation poll, followed by an exact matching post-read.

A successful CREATE|EXCL acknowledgement is itself ownership evidence. Install intent alone is not. This requirement applies to both SAs and policies, and the hostile tests should cover pre-existing exact matches as well as the first-poll observer-loss case.

[VerifiedOrganic]

Missing hostile regression: indeterminate policy Owned

Please add a deterministic test that makes a policy-only install return XfrmError::StateIndeterminate, then classifies the exact remaining policy candidate as Owned.

Assert that:

• recover returns XfrmInstallRecoveryError::IndeterminatePolicyOwnershipUnsupported;
• the backend policy-removal count remains zero;
• the exact candidate and requires_readback() remain present after the rejected recovery;
• retry remains fail-closed and commit cannot transfer ownership.

Also make Absent and Foreign retirement behavior explicit in separate cases: each must perform zero removal and leave the journal Recovered with an empty plan.

This locks the deliberate no-exact-policy-query contract and prevents a future state-machine change from turning policy install intent into deletion authority.

[VerifiedOrganic]

Adversarial review: first-polled recovery has no visible ownership claim

The install-side first-poll gap is fixed, but the same scheduling window remains in XfrmInstallJournal::recover.

On first poll, recover obtains a runtime, spawns recover_inner, and waits on the JoinHandle. The journal does not validate or claim the recovery until the owned worker first polls recover_inner. On a current-thread runtime, after manually polling the recovery future exactly once but before yielding to the spawned worker:

• recovery_running is still false;
• recovery_inflight is still empty;
• public ownership still reports the pre-recovery SaAcquired, PolicyAcquired, or Complete state;
• commit() can still succeed, proving that no recovery claim exists yet.

Two queued recovery workers remain serialized once they begin polling, and a successful concurrent commit prevents their internal deletion. The consumer hazard is earlier: dropping the first-polled observer can make a supervisor believe no recovery is live and release its namespace-wide XFRM writer fence, while the detached owned worker can later begin DELPOLICY or DELSA without that exclusion.

Required invariant: once a recovery future has been first-polled and scheduled, its journal must visibly retain the recovery claim until the owned worker reaches a terminal state. Classification validation and the recovery_running claim should happen atomically before spawn; the recovery guard can then move into the owned worker so spawn/task loss poisons the journal instead of silently releasing the claim.

Please add a deterministic current-thread regression that:

1. completes an acknowledged staged install and creates an Owned generation-bound classification;
2. manually polls recover exactly once before the spawned worker can first poll, then drops the observer;
3. proves public ownership exposes a live recovery claim and the exact recovery plan remains retained;
4. proves commit() returns RecoveryInProgress and a second recovery attempt is rejected while the queued worker owns the claim;
5. yields to the detached worker, proves it reaches a paused backend removal, and keeps the claim live until that removal returns;
6. releases the backend and proves a single exact removal and terminal Recovered state.

Cover the single-object and composite recovery paths because both use this shared entry point.

[VerifiedOrganic]

Adversarial review: legacy Mock SA query accepts a scoped state Linux rejects

The candidate makes Linux query_sa an unscoped compatibility boundary: after GETSA it returns StateMismatch when the kernel record carries if_id: Some, while query_sa_exact is the API that can authorize a matching scoped identity.

MockXfrmBackend::query_sa still looks up the core tuple and exact mark, then returns the stored SaState without checking record.identity.if_id. A legacy public Mock query therefore succeeds against a scoped SA that the Linux backend rejects. This can false-green a consumer or harness that accidentally drops the XFRM-interface dimension.

Please align the public Mock query boundary and add regressions that:

1. install an SA with a nonzero if_id, call legacy query_sa, require XfrmError::StateMismatch, and prove the original record remains unchanged;
2. call query_sa_exact with the matching if_id and require the original exact state;
3. call query_sa_exact with a different if_id and require XfrmError::StateMismatch, again proving the original remains retained.

Keep legacy removal semantics out of this change: Linux DELSA lookup itself does not discriminate on if_id, and the explicit exact-removal boundary already handles that risk. This query-only parity gap does not block the ePDG's initial if_id: None SWu path, but it matters for a harness that must not hide dropped scope.