feat(cli): declare secret requiredness at add time, extracting manifest_edit

[djbclark]

Summary

secretspec add could only ever write a declaration that inherits
[defaults] required from its profile — it emits a description key and
nothing else. A secret that only some environments need had no CLI path to
being declared optional, short of editing the manifest by hand.

That is not cosmetic: check fails on a required-but-unset secret and passes
on an optional-but-unset one, so the missing flag decided whether check, and
anything gating on it, goes red in an environment that legitimately does not
set the secret.

Two commits, kept separate so the refactor stays readable:

1. refactor(cli): extract manifest_edit module — moves
   add_secret_to_manifest (and validate_add_secret_name) out of cli into
   a new manifest_edit module behind its own manifest-edit feature, which
   cli still enables. Behavior unchanged; a caller that only needs to add a
   declaration can take that feature alone, without cli's shell-completion
   tooling (clap_complete, clap_complete_nushell, is_executable).
2. feat(cli): declare secret requiredness — adds --optional and
   --required.

They are in one PR deliberately: the second commit adds a parameter to
add_secret_to_manifest, and the first is what first makes that function
pub. Landing them together means no published signature ever changes.

Requiredness is tri-state

None omits the key entirely (unchanged behavior, byte-identical output),
Some(true)/Some(false) write it explicitly.

Collapsing that to "omitting the flag means required" would be wrong, and this
is the part worth checking: a profile carrying defaults = { required = false }
makes an omitted key resolve to optional. So --optional on its own would
leave "declare a required secret in that profile" unreachable — hence
--required as well. The two are conflicts_with, so the handler never has to
silently pick a winner.

No flag is offered for the at_least_one/exactly_one presence-group form of
required: it spans several secrets at once and does not fit a single-secret
declaration.

Validation

• cargo test --package secretspec --all-features -- manifest_edit — 7 passed
• cargo test --package secretspec --all-features cli::tests::add — 5 passed
• cargo test --package secretspec --all-features --lib — 1256 passed, 26
  pre-existing failures (21 provider::sops::* from the sops CLI not being
  installed, 5 cli::completion::tests that depend on the working directory).
  Both sets fail identically on this branch with the second commit reverted.
• cargo fmt --all -- --check
• cargo clippy -p secretspec --no-default-features --features cli — no new
  warnings

Tests cover the emitted text for all three states, that an explicit
requiredness survives into the loaded Config rather than only into the bytes,
that a document mixing a presence group, a full table and a quoted dotted key
is left untouched, and that the two flags are refused together.

[djbclark]

@domenkozar when you get a chance, could someone approve the workflow runs on this PR? Every run is sitting in action_required and CI has never actually executed here — across both the original push and the amend — so there's no signal on it either way. That's also what's keeping the PR in UNSTABLE rather than a clean state; nothing is failing.

For context on what's here now: this carries two commits, kept separate so the refactor stays reviewable on its own.

• 8025fbb extracts the manifest editing out of cli/mod.rs into a manifest_edit module (the original scope of this PR).
• e917888 builds on it to let add declare requiredness, via --optional / --required.

They're together deliberately. The second changes the signature of add_secret_to_manifest, which is private on main and only becomes pub in the first — so landing them in one PR means no published signature ever changes. Splitting them would create exactly the break that merging them avoids.

Locally: cargo test -p secretspec passes, with the new manifest_edit tests covering round-tripping a document that mixes a presence group, a full table, and a quoted dotted key.