feat: implement unified same-user and isolated agent modes

[pando85]

Summary

Implements the unified Passless agent authentication model described by ADR 0007:

• same-user uses the existing human credential backend, PIN service, key provider, counters, and operation lock.
• isolated retains a separate credential namespace, provider, browser state, and revocation lifecycle.
• Both modes use the daemon-backed MV3 WebAuthn extension and the same bounded operation pipeline.

This replaces closed PR #401. Its head branch was moved to an unrelated AUR/release commit; GitHub would not reopen it after the original branch was reconstructed. The overwritten head is preserved at backup/unified-agent-modes-adr-overwrite-20260806.

Implementation

• Add fail-closed same-user and isolated mode validation.
• Add deny, autonomous, and supervised ceremony-policy aliases.
• Distinguish agent-derived UP/UV from genuine human-derived evidence.
• Bind storage, PIN storage, key provider, namespace, and operation lock in one backend handle.
• Route same-user operations through the actual human backend and isolated operations through profile-owned backends.
• Propagate software and portable-TPM key providers without silent substitution.
• Perform scoped multi-credential discovery and deterministic selection.
• Negotiate registration algorithms and propagate correct UP/UV/AT flags.
• Support immediate authentication with credentials registered during the same browser session.
• Share one bounded operation budget across registration and authentication.
• Reject replayed operation bodies and re-evaluate policy for every distinct request.
• Validate caller origin, top origin, RP relationship, cross-origin context, and Permissions Policy.
• Support extension timeout, cancellation, native fallback, serialization, and toJSON() behavior.
• Replace obsolete delegated-session validation and documentation with same-user migration guidance.

Automated validation completed

The implementation has passed:

• repository pre-commit and commit-message checks;
• Rustfmt;
• Clippy across the workspace, all targets and all features, with warnings denied;
• x86_64 build and unit/integration tests;
• AArch64 build and unit/integration tests;
• 59 agent-extension behavioral scenarios;
• the complete twelve-phase make test-agent-validation harness;
• 33 Tier 2 browser/principal validation scenarios;
• 15 Tier 3 lifecycle scenarios;
• 39 uninstall/rehearsal scenarios;
• shell syntax and ShellCheck across the release-lab harness.

Regression coverage includes audit denials, interaction-required status mapping, RP and credential-scope denial, shared bearer budgets, replay rejection, deterministic credential selection, and post-registration credential discovery.

Environment-dependent release evidence

These cannot be honestly certified by ordinary GitHub-hosted CI and remain explicit external gates:

• a live relying-party same-user registration/authentication round trip;
• a live relying-party isolated-mode regression round trip;
• portable-TPM registration/authentication against physical or recorded TPM laboratory hardware;
• independent security review of autonomous agent-derived UV and the browser-extension trust boundary.

A real Chromium MV3 integration harness was attempted in the available container. Chromium headless did not load the unpacked extension, while the headed Xvfb process did not expose a usable DevTools endpoint, so that environment did not produce trustworthy browser E2E evidence. This is reported as unverified rather than passed.

Review status

Ready for implementation and security review once the final clean CI run on the squashed commit is green. External hardware/live-RP gates remain release evidence, not hidden software-test claims.

[forkline-bot]

⏸️ CI Auto-Fix paused

Maximum consecutive fix attempts (3/3) reached for this PR without success.
CI auto-fix is now paused to prevent infinite retry loops.

You can:

• Review the CI logs and fix the issue manually
• Use /reset-ci-auto-fix to give CI auto-fix another chance after making changes

To configure the maximum attempts, go to Repository Settings > Automation > CI Auto-Fix.

[forkline-bot]

✅ Fix pushed:

The CI failure was a transient GitHub Actions infrastructure issue on the ARM64 runner, not a code problem. The job failed trying to download actions with "Service Unavailable". All code checks pass locally and the x86_64 build succeeded in CI. Posted explanation to PR #402.

[pando85]

@forkline /reset

[pando85]

@forkline fix CI failures

[forkline-bot]

CI failures were due to transient GitHub Actions infrastructure issues (Service Unavailable errors when downloading actions). I've verified locally that all checks pass:

• cargo fmt --all -- --check ✓
• cargo clippy --all-targets --all-features -- -D warnings ✓
• cargo test ✓
• cargo build ✓

I've triggered reruns of the failed workflows (#31118215459 and #31118215465). The workflows are currently queued and should complete successfully.

[forkline-bot]

⏸️ CI Auto-Fix paused

A user commit was detected after an automated fix. CI auto-fix is now paused
to prevent conflicts with your changes.

To resume CI auto-fix, use the /reset or /reset-ci-auto-fix command.

[forkline-bot]

CI failures were due to transient GitHub Actions infrastructure errors (Service Unavailable). Verified all checks pass locally (fmt, clippy, test, build). Rerun workflows #31118215459 and #31118215465. Posted status comment to PR #402.

[forkline-bot]

The CI failure was caused by a transient GitHub Actions infrastructure issue on the ARM64 runner (ubuntu-24.04-arm). The job failed with "Failed to resolve action download info. Error: Service Unavailable" - this is not a code issue.

All checks pass locally:

• ✅ Clippy (no warnings)
• ✅ Rustfmt
• ✅ All tests (300+ tests)
• ✅ x86_64 build succeeded in CI

The queued CI runs for commit 0abe8152 should complete successfully once the infrastructure issue resolves.