Support agentless one-shot operations and managed CI sessions

Problem

The current CLI couples several ordinary lockbox operations to the Lockbox Session Agent through local_vault(). This makes the agent an availability requirement rather than an optional session/cache facility.

On a desktop, a stopped agent can normally be started automatically. However, if the agent is unsupported or cannot start, commands such as lbx add cannot fall back to opening the vault and lockbox for a single operation. lbx open also cannot work agentlessly because its purpose is to persist unlocked state between processes.

The current low-level CI workaround also exposes too much runtime plumbing. A job may need to configure values such as:

• LOCKBOX_VAULT_PASSWORD
• LOCKBOX_VAULT_DIR
• LOCKBOX_SESSION_AGENT_DIR
• agent configuration overrides

Only the credential should normally be user-facing. Temporary directories, agent lifecycle, platform-store policy, and cleanup should be managed by reVault.

The draft docs/ci_cd.md design for lbx vault ci bootstrap and lbx vault ci open is the right place to establish a simpler contract.

Proposed desktop contract

Treat the session agent as a session/convenience facility, not a prerequisite for core encrypted-file operations.

Situation	Expected behaviour
Agent is supported but stopped	Start it automatically
Agent is running	Use cached session keys
Agent cannot start	One-shot commands unlock and operate in-process
lbx open without an agent	Explain that persistent sessions are unavailable
Non-interactive execution without credentials	Fail immediately with explicit credential instructions
Vault is not available	operations that take a key or password still function

Commands such as add, cat, extract, list, variable, mirror, and form should be able to:

1. Resolve the vault passphrase from platform storage, the agent, LOCKBOX_VAULT_PASSWORD, a secured file, or an interactive prompt as appropriate.
2. Open the local vault directly.
3. Open the selected lockbox using a vault profile or remembered lockbox password.
4. Load the correct owner-signing key for writable operations.
5. Perform the operation in the current process.
6. Drop/zeroize decrypted material when the command exits.

We should allow read only operations to be performed without access to the signing key - maybe we need a switch to indicate that we don't need to check the signatures.

open and session remain agent-backed because their explicit purpose is to preserve state across commands.

Proposed CI contract

The CI caller should provide an encrypted CI bundle and one protected credential:

env:
  LOCKBOX_VAULT_PASSWORD: ${{ secrets.REVAULT_PASSWORD }}

run: |
  lbx vault ci open .revault/ci/production.lockbox-ci \
    --lockbox deploy.lbox \
    -- ./ci/deploy.sh

We should encourage users to provide a protected file with the vault password rather than a env var - is this the best practice in CI/CD/production environments, what about desktop usage?

vault ci open should internally:

1. Require LOCKBOX_VAULT_PASSWORD or an explicit secure input mechanism.
2. Create private temporary vault and runtime directories using the platform/CI temporary-directory defaults.
3. Restore and verify the encrypted minimal CI vault bundle.
4. Disable platform secure-storage integration for the temporary vault.
5. Attempt to start a private job-scoped session agent.
6. Open the requested lockboxes using the CI profile.
7. Run the child command with only the necessary internal environment inherited.
8. Forward signals and return the child command's exit status.
9. Stop the agent, clear cached keys, zeroize in-memory secrets, and remove temporary state on success or failure.
10. Use an agentless execution path where feasible if the runner cannot host the agent.

Users should not normally need to set LOCKBOX_VAULT_DIR, LOCKBOX_SESSION_AGENT_DIR, sleep-inhibitor settings, or other implementation variables.

Bootstrap expectations

vault ci bootstrap should:

• Create a stable, dedicated CI profile rather than reusing a developer profile.
• Produce one encrypted minimal-vault bundle.
• Generate a high-entropy vault passphrase when appropriate and display it only on an interactive terminal.
• Never print private profile recovery material.
• Optionally grant the new profile access to selected already-open lockboxes.
• Support exporting only the public key when grants will be applied elsewhere.
• Clearly separate the encrypted bundle from the protected passphrase.

Implementation notes

• Existing Vault<NoopStore> paths demonstrate that direct agentless opening is already architecturally possible.
• Consolidate direct opening into a deliberate one-shot execution path instead of adding command-specific fallbacks.
• Writable agentless operations must retain the same owner-signing and commit-authentication guarantees as agent-backed operations.
• Do not silently claim that open established a persistent session when no agent exists.
• Avoid interactive prompts when stdin is not a terminal.
• The CI agent, when used, must be isolated per job rather than sharing a desktop/default runtime endpoint.

Acceptance criteria

• On supported desktops, a stopped session agent starts transparently.
• If the agent cannot start, representative read-only and writable one-shot commands still work after securely unlocking the vault.
• lbx open reports a clear persistent-session capability error when the agent is unavailable.
• Non-interactive commands never hang waiting for a passphrase prompt.
• vault ci bootstrap creates an encrypted minimal CI bundle and dedicated profile.
• vault ci open requires only the bundle plus one protected credential from the caller.
• vault ci open manages all temporary paths, agent settings, and cleanup internally.
• Child commands can use normal lbx commands within the managed CI scope.
• Cleanup occurs on success, command failure, and termination signals.
• Agentless fallback and managed-agent CI flows have Linux, macOS, and Windows coverage where supported.
• Desktop, generic CI, GitHub Actions, and GitLab examples document only the intended high-level interface.

Review docs/ci_cd.md, local_vault(), and the existing Vault paths first. Trace the representative add, cat, extract, list, variable, mirror, and form commands alongside the vault ci bootstrap and open entry points. Done means agentless desktop operations and managed CI flows meet the listed credential, cleanup, capability-error, signal, and platform-coverage acceptance criteria.