Two terminal identity states may be unreachable through any real action

The specification describes two end states for an identity: one where every signing key has been removed and nothing more can ever be done with it, and a more permanent variant of the same thing where the identity has also been formally closed. Both are defined as real states the system should be able to recognize and correctly handle once reached.

Right now, neither appears to be reachable through any actual sequence of real, signed actions. The two operations that remove a signing key both explicitly refuse to complete if doing so would leave zero keys behind — which is a sensible safety measure on its own (it prevents someone from accidentally locking themselves out forever), but it also means there is currently no path in the system that produces the state the specification describes as fully key-less.

The existing test coverage doesn't catch this because it happens to test the safety guard itself (confirming that removing your last key is correctly rejected) rather than testing what happens once that final state is actually reached — because nothing can reach it.

This raises a real question rather than a straightforward bug: does the specification expect an actual path to this state to exist and it simply hasn't been built yet, or does the current safety guard represent the intended, permanent behavior and the specification's description of this as a reachable state should be revisited? Either answer is fine, but it needs a deliberate decision rather than remaining an open gap.

Not urgent and not something the current effort touched or introduced — this predates it. Flagging for a future pass or a direct read from whoever owns the specification's intent here.

Start by reading the specification and the two operations that remove signing keys, along with the existing tests for rejecting removal of the last key. Determine whether the key-less and formally closed states are intended to be reachable. Done means the decision is documented and the implementation, specification, and tests consistently reflect it.

Written by the indexing model from the issue text.