epic: secrets management profiles and 1Password backend support

[rianjs]

Parent: #202

Problem

cr init currently treats keyring/backend configuration as a global text-field setting. That does not match how users think about secrets: each secrets store should be configured as its own reusable lego brick with a human-readable label, then review profiles should choose which configured secrets-management profile to use.

The current design also asks users to type backend magic strings such as file or memory. We should instead show configured and available backends as menu choices and keep implementation identifiers internal.

Direction

Introduce first-class secrets management profiles:

• Each profile has a descriptive label chosen by the user.
• Each profile selects one backend from configured/available backend choices.
• Backend-specific non-secret settings are stored in config.
• Secret values themselves stay in the configured secret store.
• Review profiles select a secrets management profile instead of implicitly using one global backend.
• The init main menu exposes this as Configure secrets management.
• The old global keyring text-entry workflow should be removed once the new model is in place.

Notes

1Password support is a separate implementation seam. The underlying Byteness keyring library already includes 1Password backend implementations, but our cli-common/credstore abstraction currently does not expose those backends or their non-secret configuration.

Acceptance criteria

• cr init has a clear top-level secrets-management configuration area.
• Users can configure labeled secrets-management profiles.
• Users choose backends from visible choices, not typed magic strings.
• Review profiles can choose a configured secrets-management profile.
• Existing configs keep working through migration/default behavior.
• 1Password support is planned and implemented through the shared credstore abstraction, not one-off command logic.