feat(aiac/docs): documentation describing the AIAC end goal

[oblinder]

Parent

Sub-issue of the AIAC epic — #643.

Summary

The goal of this issue is to produce the documentation that describes the AIAC end goal: a
human-readable picture of what the system does and how its parts fit together, the specifications
that define each part's intended behavior, and a plan for validating that behavior. Documentation is
written at a level a non-implementer can follow, and is delivered incrementally alongside the phase
it supports.

Goal

Anyone — a new engineer, a reviewer, or a stakeholder — should be able to understand what AIAC is,
what each component is responsible for, and how a request flows through the system, without reading
the source code. Each implementation phase should be able to start from written documentation that
describes its intended behavior.

Deliverables (as tasks)

• Produce the Architectural Summary (inception/requirements/ARCHITECTURE-SUMMARY.md) — a
  plain-language, end-to-end overview of AIAC: the use cases, the components described in prose, and
  how a request flows through the system. This is the canonical human-readable orientation; the epic
  and this issue both link to it. Technical reference material (ports, libraries, exact schemas)
  stays in the PRD, not here.
• Produce / complete the component specifications — the documentation that describes the
  intended behavior of each part of AIAC needed to reach the end goal. Written as descriptions of
  what each component should do, kept internally consistent and cross-referenced with the
  Architectural Summary.
• Produce a test plan — a plan describing how AIAC's end-to-end behavior is validated at each
  phase (what is exercised, what "correct" looks like). This is a plan to be written, not a record
  of tests that already exist.

Documentation by phase

Documentation is delivered just ahead of the phase it supports:

Phase	Documentation that supports it
Phase 1	Service-onboarding (UC-1) behavior; how policy is read from a single written document; the identity and policy-writing components
Phase 2	The live platform trigger path; how enforcement consumes the generated rules
Phase 3	The searchable knowledge base and how the policy source is read from it
Phase 4	Policy-update (UC-2) and role-update (UC-3) behavior

Acceptance criteria

• The Architectural Summary exists and reads as a coherent end-to-end overview of AIAC that
  is understandable without reading the code.
• The component specifications describe the intended behavior of each AIAC part, are
  internally consistent, and cross-reference one another and the Architectural Summary.
• A test plan describes how each phase's behavior is validated.
• Documentation that supports a given phase is available before that phase's implementation
  begins.