tasks: decompose Phase 0a ADR foundation and mark prior tasks completed

Add 10 new tasks under tasks/architecture/ for Phase 0a (ADR writing):
- 9 ADR tasks (026-034) with dependency-ordered structure
- 1 review checkpoint task before Phase 0b spec writing

ADR dependency graph (3 generations):
  Gen 1 (parallel): 026, 029, 030, 031, 032, 034
  Gen 2 (depends on 029): 027, 028
  Gen 3 (depends on 027+028): 033
  Gen 4: review checkpoint

Also mark all 34 prior implementation tasks as completed — they
were finished but still showing as pending in the taskgraph.

tasks/architecture/adr-032-event-boundary-discipline.md

@@ -0,0 +1,45 @@
+---
+id: architecture/adr-032-event-boundary-discipline
+name: Write ADR-032 — Event boundary discipline
+status: pending
+depends_on: []
+scope: single
+risk: low
+impact: project
+level: implementation
+---
+
+## Description
+
+Write ADR-032 establishing event boundary discipline as a hard architectural constraint.
+
+The research (services.md, storage.md) identifies three distinct communication patterns with clear boundaries:
+
+1. **Domain events** (Honker streams) — internal to the owning service, for state reconstruction. Never cross service boundaries without projection.
+2. **irpc service calls** — synchronous request-response, within a node or cluster. Internal to the system.
+3. **Call protocol events** (EventEnvelope) — cross-node, cross-language integration events. These are what cross boundaries.
+
+The ADR must state this as a hard constraint, not a suggestion. Conflating these three patterns is an anti-pattern that leads to leaky event stores and coupling.
+
+## Acceptance Criteria
+
+- [ ] `docs/architecture/decisions/032-event-boundary-discipline.md` exists
+- [ ] ADR follows established format (Status, Context, Decision, Consequences, References)
+- [ ] Context explains the three patterns and why conflating them is harmful
+- [ ] Decision states: domain events stay within the owning service; irpc calls are synchronous internal boundaries; call protocol events are the only events that cross node boundaries; projection from domain events to integration events is required when crossing boundaries
+- [ ] Consequences include: prevents leaky event stores, services are independently deployable, Honker and irpc are implementation details not exposed across boundaries
+- [ ] References: research/services.md, research/storage.md, integration-plan.md
+
+## References
+
+- docs/research/services.md — event boundary discipline section
+- docs/research/storage.md — Honker integration, event boundaries
+- docs/research/integration-plan.md — ADR 032 entry
+
+## Notes
+
+> To be filled by implementation agent
+
+## Summary
+
+> To be filled on completion