tasks(arch): adopt taskgraph for architecture work — blocker tasks for deferred OQs, level mapping, status fixes

Establishes the tasks/architecture/ blocker-task half of the Safe Exit
protocol. Each deferred OQ now has an external-trigger tracker task
representing its unblocking condition, and the OQ's Blocked on field names
the tracker task ID — closing the gap where the deferral field existed but
the task-graph half was unenforced.

Changes:
- Add 6 external-trigger tracker tasks for the deferred OQs (OQ-09, 10, 32,
  41, 44, 46) under tasks/architecture/, tagged [external-trigger, deferred-oq]
- Add structured Blocked on field to OQ-09 and OQ-10 (previously used legacy
  'deferred' status with the reason in the Resolution prose); index now
  surfaces all 6 deferred OQs with concrete conditions, no placeholders
- Document the architecture-task level mapping (level: implementation for
  ADRs/specs, decomposition for spec-to-ADR breakdown, planning for backlog
  seeding, research/review direct fits) and the deferred-OQ blocker-task
  pattern in docs/sdd_process.md
- Mark architecture/safe-exit-blocker-task-mechanism and
  architecture/oq-09-10-blocking-conditions completed (implemented by this pass)
- Fix 4 pre-existing ADR-050 implementation tasks: status: done → completed
  (taskgraph enum is 'completed', not 'done') — taskgraph validate now passes
  for all 100 tasks

tasks/architecture/oq-32-multihop-use-case.md

@@ -0,0 +1,53 @@
+---
+id: architecture/oq-32-multihop-use-case
+name: External trigger — a concrete multi-hop federation use case
+status: pending
+depends_on: []
+scope: single
+risk: trivial
+impact: component
+level: research
+tags: [external-trigger, deferred-oq]
+---
+
+## Description
+
+External-trigger tracker for [OQ-32](../docs/architecture/questions/032-multi-hop-federation.md)
+(Multi-Hop Federation). This is **not actionable work** — it tracks whether a
+concrete use case for multi-hop federation has arrived. When it does, mark this
+task `completed` and the OQ moves from `deferred(scope)` to `open`.
+
+## Trigger condition
+
+A concrete deployment or use case that requires transitive op discovery across
+more than one hop — i.e., worker A needs to reach worker B's ops *through* the
+head, where the head is not explicitly re-exporting them. The one-hop model
+(head→worker, runner→hub) covers all current use cases.
+
+## What unblocking looks like
+
+When a use case arrives:
+
+1. Mark this task `status: completed`.
+2. Move [OQ-32](../docs/architecture/questions/032-multi-hop-federation.md)
+   from `deferred(scope)` to `open` (update the Status field + the
+   `open-questions.md` index tables + Deferred/Blocked section).
+3. Create an architecture task to write the multi-hop federation ADR — the
+   peer-keyed overlay model extends to multi-hop without redesign (ADR-029 §3.7),
+   but path-finding (which peer reaches which op transitively) is where the
+   design work lives. A graph library (petgraph) may pay off for multi-hop; for
+   one-hop, a nested `HashMap<PeerId, HashMap<String, ...>>` suffices.
+
+## Why this is a task, not just an OQ field
+
+The OQ's `Blocked on:` field in `open-questions.md` is the human-readable
+visibility surface ("what's parked and why"). This task is the machine-readable
+half: it lives in the task graph so `taskgraph` tools can reason about it, and
+so downstream work that depends on multi-hop being resolved can declare
+`depends_on: [architecture/oq-32-multihop-use-case]`.
+
+## Verification
+
+This task is "completed" when a concrete multi-hop use case is documented
+(e.g., in a research finding or deployment note) and OQ-32 has been moved to
+`open`.