Defer predecessor custody and Secure Enclave implementation to Phase 11

[bordumb]

Decision

Treat the custody, Secure Enclave, platform-storage, and signing code in the
experimental auths-dev/auths predecessor repository as research history and
prior art. Do not copy it into the current Auths release candidate or cite it
as production-custody evidence.

Provider-neutral contracts are part of the current SDK direction. Deployable
custody providers remain Phase 11 work governed by AP-SPEC-029 and the later
runtime, recovery, packaging, and security-review gates.

What has been migrated conceptually

• auths-author constructs exact, domain-separated external signing requests
  without owning private keys.
• auths-custody defines a provider-neutral ExternalSigner boundary and
  rejects provider output bound to a different Auths transaction.
• AP-SPEC-029 separates identity evidence, approval, and custody; defines the
  macOS helper process boundary; requires explicit software fallback; and
  preserves portable macOS, Linux, Windows, headless, and on-prem operation.
• The SDK re-exports the custody boundary without requiring a platform-specific
  helper.

These are contract and architectural migrations, not a claim that a deployable
provider has passed its gate.

Deferred predecessor ideas

macOS Secure Enclave and user presence

The predecessor Swift bridge demonstrates P-256 key creation, opaque key
handles, public-key export, LocalAuthentication user presence, and signing.
Its Rust integration used a direct FFI shape. The current repository forbids
unsafe Rust and AP-SPEC-029 instead requires a bounded, versioned helper-process
protocol with hostile-message tests, pinned build expectations, packaged
artifact verification, key invalidation, restart, rotation, and recovery
evidence.

Platform storage

The predecessor contains macOS/iOS keychain, Linux Secret Service, Windows
Credential Manager, encrypted-file, PKCS#11, Secure Enclave, and memory storage
work. Some paths are experimental or stubs, and the abstraction combines
identity-era storage concerns that are not automatically valid for the current
identity-agnostic custody boundary. Reuse requires a fresh threat model,
platform capability contract, explicit fallback behavior, lifecycle tests,
secret-zeroization review, and native macOS/Linux/Windows evidence.

Signing workflow

The predecessor commit-signing workflow contains useful lessons about agent,
hardware, and passphrase-backed fallbacks. It also accepts general commit/tag
signing inputs and belongs to a different product architecture. A current Auths
provider must sign only the exact Auths domain-separated transaction selected
by the closed custody contract; no general-purpose signing API or silent
hardware-to-software fallback is permitted.

Reconsideration trigger

Begin implementation only after the AP-SPEC-029 Phase 11 entry prerequisites
are satisfied and a bounded provider PR is authorized. At that point:

• implement the helper protocol before the Secure Enclave provider;
• keep native providers optional so the base SDK loads on macOS, Linux, and
  Windows and remains usable headlessly;
• implement software and headless providers in separate PR units;
• test transaction mismatch, cancellation, unavailable user presence,
  capability discovery, restart, ephemeral disposal, and explicit fallback;
• complete packaging, upgrade, backup, recovery, uninstall, and scoped security
  review before production claims.

Exclusions

This issue authorizes no predecessor code copy, package publication, native
binary distribution, key migration, security claim, repository archive, or
Phase 11 implementation. It records why the ideas remain visible and what
evidence is required before reuse.