feat: add keychain CLI commands

[bjesuiter]

Fixes #819

Adds a native varlock keychain CLI namespace for managing macOS Keychain-backed secrets:

• keychain set stores secrets through Varlock's own daemon/helper and can write matching keychain(...) refs back to env files.
• keychain import migrates sensitive plaintext values from an env file into Keychain using the file's schema to decide what should be imported.
• keychain fix-access grants Varlock's helper access to existing explicit keychain(...) refs, for cases where items were created by another tool.
• keychain list provides a metadata-only view of matching Keychain items.

Also updates docs and release workflows for the native Keychain/Rust signing changes, and adds tests for the new CLI parsing/import behavior.

[bjesuiter]

I finished a closeout autoreview pass and made a few follow-up fixes before marking this ready for review.

What changed in this branch

This PR adds a native varlock keychain namespace for macOS Keychain-backed secret workflows:

• varlock keychain set stores a single secret through Varlock's helper and can write the matching keychain(...) ref into an env file.
• varlock keychain import migrates plaintext sensitive values from an env file into Keychain, using the file's schema to decide which values are actually sensitive.
• varlock keychain fix-access repairs ACL access for existing explicit keychain(...) refs so Varlock's helper can read items created by another tool.
• varlock keychain list shows metadata-only Keychain inventory for inspection/admin use.
• Docs, tests, syntax highlighting fixtures, and native build/release workflows were updated around this flow.

Fixes from autoreview

The review found several real edge cases, all fixed now:

• GitHub Actions signing conditions no longer reference secrets.* directly in if: expressions. The workflow now computes a non-secret HAS_OP_CI_TOKEN env flag and branches on that instead.
• fix-access no longer mutates ACLs for an arbitrary matching item when a service-only ref is ambiguous. It now follows the same ambiguity behavior as reads and asks the user to disambiguate.
• keychain import --from ... now loads the Varlock env graph for the actual input file, instead of accidentally using the cwd/package graph for schema and sensitivity checks.
• Account-only keychain(account="...") refs are no longer silently skipped by fix-access --path. Since ACL repair needs a service in the current helper path, this now fails loudly with a clear suggestion.
• Generated keychain(...) refs now escape $ so project/profile/account names cannot accidentally trigger env-spec expansion when written back into env files.
• keychain set --write now checks whether the target env var already exists before storing the secret, avoiding a failed command that still leaves a new Keychain item behind.

I also reran lint, the focused keychain CLI tests, Swift tests, and the final autoreview. The final autoreview result was clean: no accepted/actionable findings.

CLI namespace/scoping rationale

I think the command split is in the right place semantically:

• Top-level Varlock commands should operate on the Varlock env graph, variables, and app config.
• varlock keychain ... commands should operate on the macOS Keychain backend and concrete keychain(...) refs.

That keeps varlock reveal as the env-var-level command: resolve my Varlock config and safely show a sensitive variable, regardless of which backend provides it.

The new subcommands are backend/admin operations, so they fit under keychain:

• keychain list is Keychain inventory/admin.
• keychain fix-access is Keychain-specific ACL repair.
• keychain import migrates plaintext env secrets into the Keychain backend, with schema validation keeping it tied to Varlock semantics.
• keychain set writes one secret into Keychain and optionally writes the env ref; it is not just setting an env var.

So I would avoid backend-specific duplicates of graph-level commands like varlock keychain reveal API_KEY, but the commands in this PR stay on the backend side of that boundary.