[Feature] ACP: let clients check and grant directory trust without --trust-directory #1899

Description

ACP clients have no clean way to trust a project folder. Since #1847, nanocoder --acp exits when its working directory is not trusted. A client can pass --trust-directory, which covers one run, or set NANOCODER_TRUST_DIRECTORY=1, which saves the folder silently with whatever it contains at that moment. Neither lets a client show the user what will be trusted and then save exactly that.

Use Case

• Nanocoder's own VS Code extension. It adds --trust-directory when the workspace is trusted in VS Code (docs). That flag only bypasses the startup check. Per-session plugin trust reads the saved store (withTrustedProjectPlugins), so a workspace trusted only through the flag never loads its .nanocoder/plugins/, and a later change to its config is never asked about.
• Nanocoder Desktop (Decision: how desktop project trust maps to Nanocoder's directory trust nanocoder-desktop#4). The desktop asks the user before anything project-defined runs. Today the only way to record that answer in Nanocoder's store is a short launch with NANOCODER_TRUST_DIRECTORY=1. That saves the fingerprint the folder has when Nanocoder starts, not the one the user was shown. grantDirectoryTrust takes the shown fingerprint for exactly this reason, but the variable cannot pass one. The launch also loads the project config and starts its MCP servers once with the variable set.
• Telling a refusal apart. A trust refusal and every other startup failure exit with code 1 (acp-server.ts), so a client has to match the message text to know it should show a trust prompt.
• Mixed versions. A trust entry is a path and a fingerprint, with no version, and the fingerprint inputs change between releases (69b4891 added .env and the settings that relax confirmations). The CLI and a client that bundles another Nanocoder version would each see the other's entry as changed, and the user is asked again after every switch.

Proposed Solution

1. A read-only status command, for example nanocoder trust --status --json, run in the folder. It loads no project config and runs nothing. It prints the summary describeProjectTrust builds, the fingerprint, and a status: trusted, not-trusted, changed or needs-re-approval.
2. A grant tied to a fingerprint, for example nanocoder trust --grant <fingerprint>. It saves the folder only if its current fingerprint still matches, and fails otherwise, so the user is asked about the new contents.
3. A distinct exit code when nanocoder --acp refuses for trust, separate from other startup failures.
4. A fingerprint version in each trust entry. An entry from another version reads as needs-re-approval instead of changed.

With 1 and 2, the VS Code extension could save trust once instead of passing --trust-directory on every launch, and project plugins would load.

Alternatives Considered

• --trust-directory on every launch. Per run only: project plugins never load and config changes are never checked again.
• NANOCODER_TRUST_DIRECTORY=1 on a short launch. What the desktop will do until this exists. It saves whatever is there at launch, and runs the project config once with the variable set.
• The client writes Nanocoder's preferences. Conflicts with Nanocoder owning its configuration, and the client would have to copy the fingerprint logic.
• The client lists the project files itself. Drifts from what Nanocoder fingerprints.

Additional Context

• I have searched existing issues to ensure this is not a duplicate
• This feature aligns with the project's goals (local-first AI assistance)

Related: #1847 (the ACP trust check), #1689 (trusted paths compare case-sensitively on Windows), #1660. Desktop planning: Directory trust.

Implementation Notes (optional)

describeProjectTrust, trustRecheck and grantDirectoryTrust in source/config/ already do most of the work; the command would expose them without loading the project. The exit code could sit next to the directoryTrustRefusal call in acp-server.ts.