fix(manager): show the subtree a context delete destroys, and ask before taking it

[stormer78]

Deleting a context deletes everything below it. The delete panel said nothing about that, and the omission broke in both directions.

A context holding nothing of its own read as harmless. The preview rendered "Your agent reports it holds no keys and no DIDs", needsForce was false, the panel sent force: false, and the agent refused — because sub-contexts exist. The operator was shown a refusal for a deletion the screen had just called harmless.

A context holding one key of its own read as almost harmless. force went true on the strength of that one key, the confirmation listed it, and the agent destroyed every context below and everything they held. The checkbox read "destroying the keys and DIDs listed above"; the list was one key and the deletion was a subtree.

Both are the same missing fact.

What changed

The panel names the sub-contexts first — they reframe every list under them as the subtree's contents rather than this context's — and decides force from all six of the agent's lists, not two.

contextPreviewDelete returned three of the six. aclEntriesRemoved is the one an operator most needs, since it names the subjects about to lose their authority outright rather than merely have it narrowed, and dropping it in the client meant no screen could show it however carefully it was written. It now returns the whole preview as ContextDeletePreview, and the panel renders removed-entirely and narrowed as the distinct events the agent already distinguishes.

Where the sub-contexts come from

Derived from the context list the pane already holds. vta/contexts/preview-delete/1.0 has no member naming them — trustoverip/dtgwg-trust-tasks-tf#513 proposes subContexts — and a delete that silently takes sub-contexts is exactly what this prompt exists to prevent, so it is computed rather than left out.

Matching is segment-wise, so acme-corp is not read as a child of acme. When the member lands this becomes p.subContexts and the derivation goes.

Agent side

The agent's preview under-reported the same way; OpenVTC/verifiable-trust-infrastructure#1576 makes it answer for the subtree. This PR is not waiting on it — the six arrays are rendered and counted correctly either way, and with #1576 they carry the subtree's contents rather than only the named context's.

OpenVTC/verifiable-trust-infrastructure#1575 is the more serious half: the agent was dropping sub-context DIDs' local records without removing the published log from their hosting server, which is the behaviour that prompted all of this.

Tests

tests/contexts-pane-delete.render.test.mts, four cases:

test	against the old panel
the sub-contexts that go with it are named	fails
a context holding nothing itself still asks	fails
grants and templates count as contents	fails
an empty leaf says so and needs no force	passes — the control

The control is what keeps the other three from passing vacuously.

Verification

• npm run lint (tsc -b, all workspaces) — clean
• npm test — 730 tests, 0 failures
• npm run build — clean