* fix(orcad): keep the integration credential key only in the owner-only key file
Managed servers no longer create, read or wait on the macOS login Keychain or
a Secret Service keyring for their credential master key. A record an hourly
build pointed at the keyring is migrated once: the key is copied into the key
file when it reads back without UI within 5s, otherwise a new key file is
started and old credentials show the usual reconnect error. Removes the
locked-Keychain status fields, retry, the integrationCredentials.moveKeyToFile
RPC and the Settings notice.
* fix(orcad): serialize the keyring-record migration so concurrent starts agree on one key
* docs(orcad): note the migration lock
* fix(orcad): publish the migration lock with its PID and bound every wait
* refactor(orcad): reuse the file transaction lock for the keyring-record migration
* fix(orcad): tell the user when a locked macOS Keychain hides Linear and Jira, and recover without a restart
A managed macOS host reached only over SSH keeps its login Keychain locked
after a reboot, so the server's credential key failed closed and the app
asked the user to reconnect a token that was fine. Exit 36 from
security find-generic-password (errSecInteractionNotAllowed) is now a
'locked' lookup: the server logs it once, retries the Keychain on each
credential use and before each Linear/Jira status read, and status carries
an optional credentialErrorReason: 'keychain_locked' that the app shows in
place of the generic text. Once unlocked, Settings offers a one-click move
of the same key into the owner-only key file.
* fix(orcad): keep retrying a locked Keychain after a timeout, fence the key move to the host that asked, report the lock only for credentials that need the key
* fix(settings): offer the file-storage switch to a paired browser's implicit server too
* fix(settings): route the Keychain notice and key move by the host that reported the status; sweep stale key-record staging; say the moved key is not machine-bound
* fix(orcad): sweep only this machine's key-record staging, so a shared home's other hosts keep theirs
* fix(orcad): seal integration credentials on the headless server instead of storing them in plaintext
The Node SecretStore always reported encryption unavailable, so every
credential writer on orcad fell back to plaintext. orcad now seals with
AES-256-GCM using a host-owned master key kept in the OS keyring (macOS
Keychain, Linux Secret Service) when reachable at first start, else in a
0600 profile file bound to the machine ID. A key that cannot load fails
closed instead of downgrading. Existing plaintext credentials are sealed
on startup without loss.
* docs: describe how the headless server seals credentials and its limits
* fix(orcad): unique credential staging files, no keyring items for temp profiles, isolate startup test
* fix(orcad): keep the credential key with the credentials, one record per machine
* fix(orcad): never re-key over an unreadable record, serialize first-start key creation, refuse an unrestricted key file
* fix(orcad): verify a key record's Windows ACL and wait out a concurrent first start's keyring write
* fix(orcad): keep a keyring claim and fail closed when its store result is uncertain
* fix(credentials): restrict the staged file's Windows ACL before it replaces a credential
* fix(orcad): a temporary profile never creates a key in, or re-seals, the real credential home
* ci: baseline the two single-file credential ACL restrictions
* fix(credentials): stage Windows credentials born restricted and verify the key record asynchronously; document rollback
* test(bitbucket): inject the write failure into the Windows staging writer too
Neil