macOS Secure Enclave unreachable from unsigned CLI subprocess (errSecMissingEntitlement) — document + enable the entitlement path so 'stored in SE' is real

[emooreatx]

macOS Secure Enclave unreachable from an unsigned CLI process → keychain fallback

On macOS, ciris-server runs as a subprocess (python -m ciris_server / the bundled binary launched by the desktop app), which is not code-signed with the Secure Enclave entitlement. So storage::ios SE key generation fails and falls back:

WARN ciris_keyring::storage::ios: SE key generation failed (errSecMissingEntitlement) —
     macOS CLI process lacks entitlements. Falling back to keychain P-256 key.

Result: the user's fed-ID is custodied by a keychain-wrapped P-256 key (hw_backed=false), not the Secure Enclave — so "stored in SE" is not actually true on the Mac, even on Apple-Silicon hardware that has an SE.

Ask (NON-BLOCKING — keychain fallback works today)

1. Document the entitlement requirement: SE access needs the process to carry the com.apple.application-identifier + a keychain-access-group / SE-capable entitlement, i.e. be code-signed and run from an entitled bundle. A bare CLI subprocess cannot reach the SE by design.
2. A clean SE-eligibility probe + honest report so callers can tell "SE present but unentitled" from "no SE hardware." (v8's logging overhaul already makes this much easier to see — thank you.)
3. Coordination point: for "stored in SE" to hold, the Mac app packaging must sign/entitle the bundled ciris-server (CIRISServer/desktop-launcher concern). Tracking here so the keyring side (probe + docs) and the packaging side land together.

Context: CIRISServer adds an honest custody log on its side (USER fed-ID mint — ACTUAL custody class … hw_backed). Related to #139 (the misleading "Using Secure Enclave-backed … hw_backed=false" line, addressed by the v8 logging work). This issue is the deeper reachability gap, not just the log.

[emooreatx]

v8.0.0 (#146): the logging half is done — the macOS Secure Enclave fallback now logs an unambiguous UNSIGNED/UNENTITLED BINARY — unable to use the Secure Enclave (errSecMissingEntitlement -34018) … FALLING BACK to keychain (software-grade custody, NOT the Secure Enclave, hw_backed=false) at BOTH the signer (platform/ios.rs) and storage (storage/ios.rs) wrapper paths, with structured custody=KEYCHAIN_FALLBACK / hw_backed=false fields. iOS keeps its hard-error (no fallback arm → the signed-bin requirement holds there).

Remaining (the reachability half, NOT keyring code): for 'stored in SE' to actually hold on a Mac, the app packaging must code-sign + entitle the bundled ciris-server (com.apple.application-identifier + keychain-access-group / SE entitlement). That's a CIRISServer/desktop-launcher coordination item — keeping this open to track it landing alongside the keyring's now-honest logging. A clean SE-eligibility probe (distinguishing 'SE present but unentitled' from 'no SE hardware') is a small keyring follow-up if useful for the packaging work.