Surface resolved secrets backend context in credential-bearing init flows

[rianjs]

Problem

cr init currently has a top-level secrets-management workflow for reusable credential-store definitions, and separate profile/reviewer/LLM flows that declare credential refs. Users can configure a reviewer entity without seeing enough context about where the secrets will be stored, especially when a named 1Password backend is involved.

We should keep the reusable secrets-management concept, but credential-bearing flows need to show the resolved destination inline so users do not have to mentally connect several screens.

Related: #291, #317, #347, #348.

Desired behavior

Whenever an init flow creates or edits a credential-bearing thing, show a non-secret destination summary:

• credential ref / storage label
• resolved secrets-management profile, if one applies
• resolved backend display label, such as macOS Keychain, encrypted file, 1Password desktop app, 1Password service account, or 1Password Connect
• for 1Password profiles, non-secret routing details such as vault name/id, item title prefix, item tag, and item field title when configured

The flow should not collect or display backend access tokens. 1Password service/Connect tokens remain environment-variable references configured in the secrets-management profile.

Acceptance criteria

• Reviewer entity credential steps show the resolved destination for PAT and GitHub App reviewer credentials.
• LLM API-key and Git credential collection screens retain or gain equivalent destination summaries where they use the shared credential collector.
• Named 1Password profiles show useful non-secret context: vault, backend kind, and item naming/tag/field settings when configured.
• Default/legacy OS backend paths show platform-specific copy, e.g. Automatic OS default (macOS Keychain) on macOS.
• The top-level Configure secrets management menu remains available for creating/editing reusable backends.
• Credential-bearing flows provide clear copy for users who need to change the destination: configure/select a secrets-management profile rather than editing secret values.

Design note

Do not remove the top-level secrets-management menu in this ticket. Secrets-management profiles are reusable non-secret infrastructure and are not owned by any single reviewer entity. This ticket is about making the resolved destination visible from the places where users configure credential-bearing identities/runtimes.

Empirical verification

Use tmux to drive cr init in a real PTY.

Required captures:

• Reviewer GitHub App setup with default backend shows the reviewer secret destination inline.
• Reviewer PAT setup with a named 1Password secrets-management profile shows the profile/backend/vault context without any secret value.
• A 1Password profile configured with item tag/field/title prefix displays those non-secret labels in the destination summary.
• The main menu still exposes Configure secrets management.
• No screen suggests that the top-level secrets-management profile itself is the GitHub App ID/private key.

[rianjs]

Issue 349 Plan: Surface Resolved Secrets Backend Context

Scope

Surface non-secret credential destination context inside credential-bearing cr init
flows without changing when credentials are collected or written.

Implementation

1. Add a shared destination-summary helper for init credential refs.

   • Inputs: credential ref, resolved secrets profile, config file, backendArg,
     and backendFlagSet.
   • Output includes storage ref, resolved profile label/id, backend label, and
     non-secret 1Password routing metadata when the selected profile is named.
   • For non-named legacy/default selections, use credentials.BackendMetadata
     and existing init backend-label helpers so runtime flag, environment,
     config, and automatic OS-default precedence are represented without opening
     or writing a credential store.
   • Preserve the Show draft reviewer credential status per key in cr init #348 reviewer status behavior and move it onto the shared helper.
   • Destination-summary failures must be non-fatal: missing named profile refs,
     invalid backend metadata, and unavailable automatic backend metadata should
     render an explicit non-secret credential destination unavailable style
     message rather than aborting reviewer setup or credential collection.
   • Verification: unit tests for backend precedence, legacy/default auto copy,
     named file/keychain, missing/invalid destination inputs, and 1Password
     service/connect/desktop metadata.

2. Wire the shared summary into reviewer entity setup.

   • Keep Reviewer credential status as the place where reviewer PAT/GitHub App
     destination is shown.
   • Enrich destination text for named 1Password profiles with vault, item title
     prefix, tag, and field title when configured.
   • Preserve Show draft reviewer credential status per key in cr init #348 key-status behavior even if destination context is unavailable.
   • Verification: renderer tests for GitHub App default backend, PAT named
     1Password profile, and unavailable destination context.

3. Wire the shared summary into shared credential collection prompts.

   • Add destination copy to ChooseCredentialAction, ChooseSecretSource, and
     paste prompts through existing prompt structs so Git credentials, LLM API keys,
     and reviewer credentials all get equivalent context.
   • Keep values draft-local and preserve final commit as the only write boundary.
   • If destination formatting fails, show the non-secret unavailable message and
     continue to the existing credential action/source choice.
   • Verification: prompt title/unit tests for Git, LLM API key, reviewer PAT, and
     reviewer GitHub App entries with named/default profiles.

4. Keep top-level secrets-management workflow discoverable.

   • Do not remove or hide the main menu entry.
   • Add copy in credential-bearing flows that says destination changes are made by
     selecting/configuring a secrets-management profile, not by entering GitHub App
     IDs/private keys into the top-level backend profile.
   • Never read or display service/Connect token environment variable values. If
     env var names are shown, label them only as backend-auth env var names and
     keep them visually distinct from credential keys such as github_app_id.
   • Verification: existing main-menu renderer tests plus a targeted assertion that
     Configure secrets management remains visible, and sentinel env-value tests
     for service and Connect profiles prove raw token values do not leak.

5. Update docs for the UX contract.

   • Document that destination summaries are non-secret and belong inside
     credential-bearing flows while reusable backend configuration remains top-level.
   • Verification: docs updated and linked behavior covered by tests.

Empirical Verification

Use tmux against a real PTY at 120x40 with isolated HOME/config.

Required captures:

• Reviewer GitHub App setup with default backend shows the reviewer secret
  destination inline.
• Reviewer PAT setup with a named 1Password profile shows profile/backend/vault
  context without raw secret values.
• A 1Password profile configured with item tag, field title, and title prefix
  displays those non-secret labels in the destination summary.
• Main menu still exposes Configure secrets management.
• No screen suggests the top-level secrets-management profile itself is the GitHub
  App ID/private key.

Gates

• go test ./internal/cmd/credentialcmd
• make tidy
• make lint
• make test
• make build
• tmux empirical captures above