fix(settings): name the context the wipe screen tells you to delete

[stormer78]

Follow-up to #283, same class of defect one screen over.

The wipe-profile screen ends by saying what survives, and what to run if you
want that gone too:

  Your VTA-side context, persona DID, and keys are NOT affected.
  If you want to clean those up too, run `pnm contexts delete` first.

It named no context — on the one screen that is about to remove the config file
and the keyring entry that hold the id. That is exactly why the advice says
first: sending the operator away to look the id up was sending them somewhere
that stops existing a keypress later.

After

 Wipe profile

  This will permanently remove this profile from this host:

    • openvtc config file
    • openvtc keyring entry (secured config)
    • did-git-sign config + keyring entries (if installed)
    • git config keys did-git-sign owns

  Your VTA-side context, persona DID, and keys are NOT affected.
  If you want to clean those up too, run this first:

    pnm contexts delete openvtc

  Type WIPE to confirm and press Enter:

The id rides on SettingsState from account.top_context_id, set in the same
sync_from_config pass as the rest of the pane. The command gets its own row —
the treatment every other command this TUI hands over already gets, because it
is meant to be retyped in another terminal.

Three details worth the review

• Positional, as pnm-cli's ContextCommands::Delete defines it. The
  --did flag that had to come off the identity pane's pnm acl update hint in
  feat(health): print the DID this install authenticates to the VTA as #283 is the same mistake one repo boundary away, so the shape is asserted in a
  test rather than assumed (R3.6).
• A nested context keeps its whole <parent>/<id> path — pnm addresses a
  sub-context that way, and the leaf alone names a different context or none.
• An unloaded account keeps the placeholder. No id is better than a wrong
  one in a command that deletes a context and everything under it.

Testing

Five unit tests over the rendered screen and the command builder: the id is
named, the placeholder is gone, the flag shape holds, a nested path survives
whole, an empty id falls back, and the screen still says what the wipe does
not touch — the sentence that makes the command needed in the first place.

• cargo fmt --all --check, cargo clippy --all-targets --all-features -D warnings
• RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features
• cargo test --all-features --workspace — 446 passed in openvtc, workspace green

Pre-merge checklist

- [x] No new reqwest::Client::new() / bare fetch(); all clients have finite timeouts (R1.2) — no clients; render-only
- [x] No lock held across a network await (R1.3) — n/a
- [x] No local state committed before its remote effect, or the flow is resumable with an idempotency key (R2.1) — no mutations; this changes displayed text only
- [x] Every retry is bounded + backed off; non-idempotent ops are not blind-retried (R1.4) — n/a
- [x] Accept/poll/listen loops survive transient errors (R1.5) — n/a
- [x] Acks/deletes happen only after durable handoff (R1.6) — n/a
- [x] New/changed wire types: camelCase, deny_unknown_fields where security-relevant, schema registered, all consumers updated (R3.*) — none; `pnm contexts delete`'s arg shape verified against current pnm-cli (R3.6)
- [x] Config absence = most restrictive; fail-closed if enforcement can't start (R5.*) — no context id renders a placeholder, never a guess
- [x] Logs/status claim only what was verified; background-job failures are surfaced (R6.*) — the screen still states plainly what the wipe does not remove
- [x] "Process dies on the next line" answered for every mutation touched (R2.1) — no mutations
- [x] Deviations from this guide flagged explicitly with rule numbers — none