[kalvinnchau]

Adds the native build input BUZZ_NSEC_BACKUP_CONSENT=managed. A build compiled with it backs up every local key and ignores the saved backup choice.

Why

Without the flag, the uploader runs only when choice.json holds automatic: true for the current key, service and namespace, and only first-run setup writes that file. A user who was signed in before backup was configured never goes through first run again, so their key stays at no_consent ("Automatic backup is off for this key."), and nothing in the app can change that. For an organization's build, backup is policy, not a per-user choice.

What

• nsec_backup_config::managed validates the input. Unset or empty keeps explicit consent. managed requires the backup service and namespace to be configured. Any other value fails the build.
• build.rs runs that validation alongside the existing service and namespace check.
• nsec_backup_choice::admit decides whether a pass may run. In managed builds it takes only the choice file's shared lease and doesn't parse the saved choice, so a missing, opted-out or malformed choice can't stop backup. The lease still serializes passes against choice writes. Unmanaged builds keep the existing validation. nsec_backup.rs uses it as its consent gate. Every other precondition still applies: a Builderlab session, and the key bound to the signed-in account.
• nsec_backup_choice::set: in a managed build, turning automatic backup on while a pass holds the shared lease now succeeds without writing, because the running pass already backs the key up. Without this, first run's setBackupChoice(pubkey, true) (backup.ts:184) fails with busy and reports "interrupted" when a pass started by local_key_installed is still running.
• docs/identity.md documents the input.

Unmanaged builds behave the same as before. No UI change.

Validation

• The nsec_backup lib tests pass (59), including managed_consent_needs_configured_backup, a_managed_build_enables_backup_during_a_running_pass and a_managed_build_admits_a_pass_whatever_choice_is_saved. The second test holds a pass at the upload request and checks that an unmanaged write still fails with busy while a managed one succeeds. I ran the built test binary directly because the local signed-run wrapper needs a signing identity.
• cargo clippy -p Buzz --lib --tests -- -D warnings passes unconfigured. cargo clippy -p Buzz --lib -- -D warnings passes with a managed staging configuration. cargo fmt --check passes.

Not exercised: a packaged managed build uploading an existing key. The release pipeline sets the input in a separate change.

🤖 Generated with Claude Code

[wesbillman]

🤖 Automated source review by Star Lord via Wes’s account, integrating independent Rocket (systems/lifecycle), Mantis (correctness/security) and Groot (product flows) reviews.

No actionable correctness or security findings at head d1ff286ae7e9e612e59267bbb597298961f5864a against base c3c46c50352f13dd1b1b8a966de01e7a05f7b72e. The malformed-consent failure identified on the earlier revision is resolved in source: managed admission now acquires only the shared lease, and the named _consent binding retains it through the backup pass. Unmanaged consent validation and the account/key checks remain intact. The added admission test covers missing, false and malformed choices plus exclusion of concurrent choice writes.

Optional documentation cleanup: qualify the “Automatic backup consent hooks” section in docs/identity.md for managed builds, so its description of future automatic uploads agrees with the new policy.

Source-only review of the change, callers, lifecycle, test source and public PR description (no attachments). We did not run tests, builds or the app, or independently verify CI. Helper-level coverage does not establish a packaged managed build uploading an existing key; that remains unverified. This is a COMMENT review, not approval.