Support non-exportable and policy-controlled configuration bundle signing

## Outcome

Relay and Notary configuration bundles can be signed without exporting private key material to Registryctl, while preserving exact bundle identity, review intent, signature verification, redaction, and anti-rollback behavior.

Roadmap default: 1.2. Reprioritize only when a release-scoped deployment requirement prohibits exportable configuration-signing keys or mandates multi-party approval.

## Design checkpoint

Before implementation, define:

- a provider-neutral signing-request and signature-import contract;
- exact protected headers, algorithm allow-list, key identifier binding, and public-key discovery;
- local PKCS#11, remote KMS/HSM, and delegated signing boundaries;
- authentication, timeout, retry, cancellation, readiness, and audit behavior;
- whether threshold or multi-party approval is required, and how it differs from the current any-enabled-signer trust-anchor model;
- offline and disconnected signing behavior; and
- rotation, signer removal, compromise, recovery, and break-glass procedures.

The design must keep cryptographic integrity separate from human workflow. A signature proves authority of the configured key, not that an institutional approval process occurred.

## Required behavior

- Registryctl produces a bounded signing request over the exact bundle manifest and file closure.
- An external signer returns a signature without receiving secrets or unrelated project artifacts.
- Registryctl imports and verifies the signature against the intended product, environment, stream, instance, sequence, algorithm, and signer.
- Provider failures cannot partially sign, activate, mutate anti-rollback state, or expose private provider diagnostics.
- Provider references and operational metadata are redacted according to an explicit safe catalog.
- Local-file signing remains available only where the support matrix permits it.

## Definition of Done

- [ ] A public design decision records threat model, provider contract, algorithm policy, trust model, and approval semantics.
- [ ] At least one non-exportable local provider and one remote signing test double complete bundle signing and verification end to end.
- [ ] Signature import rejects altered requests, wrong bundle identity, wrong signer, wrong algorithm, replay, stale sequence, missing closure, and ambiguous key selection.
- [ ] Timeout, retry, provider unavailability, rotation, signer disablement, and recovery have bounded, value-free behavior.
- [ ] No private key, PIN, credential, provider path, remote endpoint, raw provider error, project secret, or source value enters a bundle, report, posture output, log, or diagnostic.
- [ ] If threshold signing is included, tests prove the exact m-of-n policy and distinguish cryptographic quorum from human approval evidence.
- [ ] Documentation covers signer setup, ceremony boundary, verification, rotation, compromise, recovery, and supported-provider limitations.
- [ ] Existing signed bundles and trust anchors have a documented compatibility and migration path.

## Non-goals

- Building an institutional approval or key-management service.
- A generic secret URI accepted in every configuration field.
- Claiming certification of arbitrary HSM or KMS products.
- Allowing an external signer to mutate bundle contents.

## Related work

- #43
- #74
- #122
- #361
- #502

No implementation files, tests, or entry points are identified in the issue. Start by reviewing related issues #43, #74, #122, #361, and #502, then define the provider contract, trust and approval model, failure behavior, and compatibility path; done requires the listed design decision, end-to-end provider tests, rejection and redaction coverage, and documentation.

Written by the indexing model from the issue text.