fix(agents): break the hedging-at-the-root pattern — deferred(unclear), impacts field, reviewer detection

Address the root cause of rework-causing hedging: the architect was
put in a logical bind where it couldn't express justified uncertainty
('the pieces exist but the shape isn't clear yet'). The only options
were 'decide now' (premature) or 'deferred(scope)' (false — the
information isn't missing, it's un-synthesized). The agent picked
deferred(scope) with a circular blocking condition (OQ-64 blocked on
OQ-55, OQ-55 needs OQ-64) because there was no honest way to say 'I
can see the pieces but I can't see the shape.'

Changes to the architect role spec:
- Add deferred(unclear) state: the pieces exist but the composition
  isn't clear; resolution requires investigation (work through
  examples, POC), not waiting. Has an investigation target and an
  impacts field.
- Add 'Impacts' field to the OQ format: what does this block
  downstream? Be specific ('blocks the first hub deployment because
  the hub dials workers' not 'blocks the hub crate'). The triage
  signal that makes deferral urgency visible — the field that would
  have made the AlknetClient circular hedge visible.
- Add circular-reasoning guard to self-review: 'check that your
  blocking condition isn't a prerequisite of the thing you're
  deferring.'
- Trim anti-patterns #9-#11 (hedging synonyms catalog, ~40 lines):
  detection belongs in the reviewer, not the architect's self-review.
  The architect is too close to its own reasoning to see its own
  circular hedges.
- Trim door-types section (30→10 lines): keep the one-paragraph
  summary, cut the elaboration.

Changes to the architecture-reviewer role spec:
- Add Decision Quality (F) category: false-deferral check
  distinguishing three cases — (1) hedging on a resolved decision, (2)
  false deferral / circular hedge (the blocking condition is a
  prerequisite of the thing being deferred), (3) legitimate deferral.
- Add Impacts Field Coverage (G) category: check that unresolved OQs
  have specific impacts fields.
- Note: the Decision Quality category is often the highest-value
  check on poorly-defined projects — the architect cannot self-review
  it (circular reasoning is invisible from inside the circle).

Retrofit existing OQs:
- Add Impacts field to all 16 unresolved OQs (10 deferred, 6 open).
- Update OQ-63 (TlsError shape) to reflect ADR-087's client-side
  addition — the error type now covers both server and client
  variants.
- Move OQ-65 (WebSocket carrying channels) to alknet-http theme
  (done in prior commit; this commit adds its impacts field).
- Verified: no circular reasoning found in existing deferrals. The
  AlknetClient hedge (OQ-64) was the circular one; it's already
  resolved by ADR-087.

docs/architecture/questions/063-tlserror-shape.md

@@ -2,9 +2,10 @@
 
 - **Origin**: `docs/architecture/crates/tls/README.md`
   (`TlsError` is referenced as the `Result` error type in
-  `TlsServerConfig::new`, `for_quinn()`, and the crate's public
-  signatures, but is never sketched or defined); ADR-082 (same —
-  `TlsError` in signatures, no shape).
+  `TlsServerConfig::new`, `TlsClientConfig::new`, `for_quinn()`, and the
+  crate's public signatures, but is never sketched or defined); ADR-082
+  (same — `TlsError` in signatures, no shape); ADR-087 (extends the
+  surface to `TlsClientConfig::new` — the client-side error variants).
 - **Status**: open
 - **Door type**: one-way (the error type is the public API surface of
   `alknet-tls`; changing it after consumers exist is a breaking change
@@ -12,8 +13,14 @@
 - **Priority**: high (an implementer cannot write the crate without
   deciding this; guessing produces divergent shapes — one thin
   `rustls::Error` wrapper vs a 10-variant enum with per-path context)
+- **Impacts**: Blocks `alknet-tls` implementation — both
+  `TlsServerConfig::new` and `TlsClientConfig::new` reference `TlsError`
+  in their signatures. Blocks the hub's assembly-layer wiring (which
+  calls both). This is the next decision needed before the TLS crate
+  can be implemented.
 - **Resolution**: Not yet decided. The shape needs to cover the failure
-  modes across all four identity paths:
+  modes across all server identity paths **and** the client verifier
+  paths (ADR-087):
 
   - **Cert/key loading** (`X509`: file read + PEM parse;
     `SelfSigned`: rcgen generation) — currently `io::Error`-wrapped in
@@ -30,6 +37,14 @@
     returned from `new`), so `new`'s ACME path may only need to cover
     "ACME feature not enabled but `TlsIdentity::Acme` configured"
     (currently an `io::ErrorKind::Unsupported`).
+  - **Client verifier construction** (ADR-087) — `TlsClientConfig::new`
+    builds a `rustls::ClientConfig` with ADR-034's verifier selection.
+    Failure modes: verifier construction error (bad fingerprint format,
+    CA store init failure), unknown-remote fail-closed (not an error to
+    return — it's a `Result::Err` the caller gets for trying to connect
+    to an unknown raw-key remote), provider init failure. These
+    overlap with the server-side rustls-build errors but have
+    client-specific context (verifier selection inputs).
 
   The open question is the granularity: a single `TlsError` enum with
   variants per failure category (cert-load, rustls-build, quinn-wrap,