feat(review 006 Unit 2): additive OperationSpec.description disclosed via discovery (E-02)

- OperationSpec gains description: Option<String> (builder
  with_description, defaults None; no struct-literal construction
  sites exist, so additive by construction)
- spec_to_json_pub emits description when set; rebuild_spec_for
  parses it back — the field survives from_call discovery and
  op/register announcement (same round-trip pattern as
  resource_id_path / publish_schema)
- services/list and the local-ops half of services/list-peers emit
  description when set; output-schema docs on both listing specs and
  operation_spec_schema advertise the field
- Tests: builder/default, emit/omit, listing emission, schema
  disclosure, schema-doc presence, round-trip + absent-stays-absent
  (8 new; 616 total)
- Docs: review 006 Unit 2 marked IMPLEMENTED; ADR-047 §6 amendment
  records the E-02 discovery decision (listing enrichment lands, the
  channel/resources/subscribe half stays deferred); OQ-40 gains the
  load-bearing note; operation-registry.md struct + listing docs;
  CHANGELOG

Verification: cargo test (616 pass), clippy -D warnings (host +
wasm32), fmt --check, cargo doc --no-deps, wasm32 check — all clean

docs/architecture/decisions/047-openable-alpns-are-operations.md

@@ -8,7 +8,40 @@ Accepted (amends ADR-037; refines ADR-044, ADR-046; §4 amended
 registration, 2026-08-13)"; amendment #2 (2026-09-03) — the
 per-connection registration mechanism is the **per-session fork of the
 base registry installed as the session's dispatch registry**, not the
-connection overlay — see "Amendment (§4 mechanism, 2026-09-03)" below)
+connection overlay — see "Amendment (§4 mechanism, 2026-09-03)" below;
+§6 amended 2026-09-06 — the static half of discovery gains an additive
+per-op `description` on the listing, the dynamic half stays deferred
+— see "Amendment (§6 listing enrichment, 2026-09-06)" below)
+
+## Amendment (§6 listing enrichment, 2026-09-06)
+
+Review 006 E-02 (from the alktunnels Phase 0 sweep) made §6's dynamic
+half load-bearing for the first time and asked for a decision on the
+static half. Decision: **both halves of the "static per-op" split gain
+what is cheap today; the dynamic half stays deferred** (OQ-40, now
+with a "load-bearing for alktunnels discovery UI" note in
+`open-questions.md`; alktunnels v1 uses config-known op names):
+
+- `OperationSpec` gains `description: Option<String>` — a human-
+  readable op description, set via `with_description` at registration.
+  Additive (defaults `None`; no struct-literal construction sites
+  exist — all sites use `OperationSpec::new`).
+- `services/list` (and the local-ops half of `services/list-peers`)
+  emit `description` when set — one round-trip answers "which ops
+  exist and what are they for" without the N+1 `services/schema`
+  sweep. The output-schema docs on both listing specs and on
+  `services/schema`'s `operation_spec_schema` advertise the field.
+- `spec_to_json_pub` emits it when set; `rebuild_spec_for` parses it
+  back — the description survives discovery and peer announcement
+  (`from_call`, `op/register`) like every other additive spec field
+  (`resource_id_path`, `publish_schema` round-trip the same way).
+
+Scope note from E-02 stands: the listing field describes **the op**,
+not **the produced resource set** (a tunnel producer registers one op
+and N resources). "Which tunnel resources may I open, live" remains
+`channel/resources/subscribe`'s job (§6's dynamic half, ADR-037 §
+`channel/resources/subscribe`) — deferred until a consumer needs live
+resource discovery.
 
 ## Amendment (§4 mechanism, 2026-09-03)