Task: Close the ores.shell remnants

They live in projects/ores.shell/application/src/app/commands/trading/ and they are the shell surface of ores.trading entities. Measured against that component's models:

Their verbs are get (a paged list, not the canonical get <key>), add, delete and history, which is a subset of what generation produces and with a non-canonical spelling. ore_commands.cpp is not in this set: it is the ORE document round trip, it models no entity, and nothing supersedes it.

Eleven of them need :ores.cpp.shell-command.enabled: true on their model and a regeneration; four need a model first. Both are ores.trading work, and the regeneration cannot be narrowed to the shell facet, so it carries that component's drift. Remove the units only where the generated replacement exists, and record each removal with the unit that replaces it.

accounts sessions aborts against the live fleet:

✗ Command failed: accounts sessions (from_iso8601_utc: missing UTC designator
  (Z, +00:00, or +00) in: 2026-09-27 12:15:14)

The session listing formats a timestamp the service returns in a shape the parser refuses. Fix the parse or the producer, whichever is wrong, and prove the verb answers against the live fleet.

bootstrap_smoke.ores is not idempotent: it creates the tenants acme and example, so a second run collides. The recipe is tangled from doc/recipes/shell/provisioning/bootstrap_smoke.org, so the fix is in the org source.

A capability duplication, not a name collision. The generated authorization menu already carries assign-role, revoke-role, get-account-roles, get-account-permissions and suggest-role-commands, so the hand-written accounts verbs of those names do the same job at a different address. Resolve each one: retire the hand-written verb and point callers at the generated one, or keep it and record why the addresses both earn their place.

component_registry.py carries an accepted exception on item S01 for iam whose reason reads "registered after the generated aggregator, so some overlapping verbs are shadowed". #2272 made that impossible: a second registration throws, and the hand-written unit extends the generated menu. The reason is rewritten to describe what the registry now enforces and what remains open. This is a documentation change; no behaviour moves.

The scaffold said fourteen. The tree holds fifteen units that build a menu, and the classification is what matters rather than the total: eleven had a model whose shell facet was off, four have no model at all, and ore_commands is not superseded by anything because it is the ORE document round trip rather than an entity surface.

The eleven are retired. Their model gains the shell facet, the generated unit appears, and the hand-written unit is deleted rather than kept beside it, which it could not be in any case: the generated header sits on the same include path as the hand-written one. The surface moves with the convention, which is the point of the item: the paged read is list rather than get, get is a key read, and history is versions and version. Measured before the change, no recipe and no script called any of the eleven menus, so nothing that answered stops answering.

The four with no model are not retired, because nothing supersedes them yet: commodity_instrument, composite_instrument, credit_instrument and scripted_instrument need a model written before generation can replace anything, and that is ores.trading work.

accounts sessions is fixed at its source. The platform wrote the database timestamp form and provided no reader for it, so the shell reached for the ISO reader, which requires a UTC designator the stored form does not carry, and the throw aborted the whole listing. from_db_string is the missing inverse, and both readers now share one parser so their separator handling cannot drift apart. Verified on the failing path: after a logout and a fresh login, the closed sessions render their End and duration, including the timestamp the original error named.

bootstrap_smoke.ores cannot be made idempotent from inside a recipe, and this is recorded rather than worked around. Three of its steps refuse a system that already holds what they create, and a shell recipe has no conditional and no way to tolerate a command's failure. The page now states the precondition, gives the destructive reset as the way to run it again, and names the gap underneath: --continue-on-error is a flag the argument parser knows and the script runner never reads.

The capability duplication is resolved per verb. Four hand-written account-role verbs were exact duplicates of four on the generated authorization menu, same arguments and same effect, and are retired with their helpers. The service generated the suggested command strings naming the verb that was retired, so ores_iam_generate_role_commands_fn now names authorization assign-role, applied to the live database and read back. Four recipes follow. permissions suggest stays, with the reason recorded: its identifier is a hostname or a tenant id in one argument where the generated suggest-role-commands takes three separate ones, and the provisioning recipes call it in that form.

The reason is rewritten to describe what the registry enforces and carries the measured surface rather than a count. The overlapping-registration half no longer describes anything; the open half is unchanged and is the half that matters.