[Curriculum] Architecture sync — migrate VerificationResult model to DiagnosticResult + proof_ref

[rahuldass19]

Problem

The curriculum teaches QWED's philosophy correctly — deterministic verification, fail-closed, proof before trust. But it maps that philosophy to an obsolete architecture model.

The entire course uses VerificationResult with a verified: bool field:

result = verifier.verify(...)
if result.verified:
    # trust the output

This binary model was replaced in v5.2.0 by DiagnosticResult with three categorical states — VERIFIED, BLOCKED, UNVERIFIABLE — and a mandatory proof_ref on VERIFIED:

result = verifier.verify(...)  # returns DiagnosticResult
if result.status == DiagnosticStatus.VERIFIED and result.proof_ref is not None:
    # trust the output — proof artifact exists

This is not a version bump. It is a different mental model:

Old (VerificationResult)	New (DiagnosticResult)
Binary: verified == True/False	Categorical: VERIFIED / BLOCKED / UNVERIFIABLE
No proof artifact required	proof_ref mandatory for VERIFIED
Confidence scores used as signals	Advisory checks structurally separated from verdicts
Diagnostics mixed with explainability	Layer 1/2/3 architecture: agent-safe messages, developer fields, proof artifacts

A student completing the current curriculum learns the right philosophy but the wrong technical model. When they encounter the real v5.2.0 codebase, every example fails and every result type is unfamiliar.

Scope

Must change

Location	What to update
ARCHITECTURE.md	Rewrite result states diagram to show VERIFIED / BLOCKED / UNVERIFIABLE + proof_ref. Replace "Result States Matter" section with DiagnosticResult 3-layer model
GLOSSARY.md	Update VerificationResult → DiagnosticResult. Add entries for proof_ref, advisory_checks, constraint_id
CHEAT_SHEET.md	Replace result.verified pattern with result.status == DiagnosticStatus.VERIFIED
Module 0: 00-proof-vs-confidence.md	Update "Proof vs Confidence" mapping to use current status names
Module 3: README.md	Replace all result.verified code examples with result.status patterns
Module 3: examples/financial_calculator.py	Update VerificationResult → DiagnosticResult
Module 3: examples/healthcare_dosage.py	Same
Module 8: README.md	Update interceptor result handling
Module 9: README.md + lab-files/	Update CI gate check to use diagnostic.status
Module 11: README.md + exercises	Update IRAC result model
Module 12: README.md	Already uses IRAC — verify alignment with DiagnosticResult structure
Module 13: README.md	Update "BLOCKED" handling to DiagnosticResult
Capstone: README.md	Update result.verified pattern to DiagnosticResult

Must add

• Principle 9 (Diagnostics ≠ Explainability) — This principle is directly enforced by DiagnosticResult's 3-layer architecture. Currently only Module 12 teaches it. Add a dedicated section in Module 0 or a new subsection in ARCHITECTURE.md explaining why structured diagnostics (Layer 2 developer_fields) are fundamentally different from AI model explanations.

Must not change (yet)

• Import paths (qwed_sdk → actual package) — tracked separately in Issue 2
• Version pins — tracked separately in Issue 3
• Ecosystem coverage — tracked separately in Issue 4

Acceptance criteria

• ARCHITECTURE.md result states diagram updated to DiagnosticResult with VERIFIED / BLOCKED / UNVERIFIABLE + proof_ref
• Every code example using result.verified replaced with result.status == DiagnosticStatus.VERIFIED
• proof_ref explained in glossary + architecture docs
• advisory_checks concept introduced with clear "advisory never decides" boundary
• Principle 9 (diagnostics ≠ explainability) taught at least in one module beyond Module 12 (preferably Module 0 or ARCHITECTURE.md)
• No VerificationResult (old model) remains in any code example or architecture doc

Non-goals

• Changing import paths or package names (Issue [Curriculum] Import path and package reality audit — make every code example runnable #8)
• Updating version numbers (Issue [Curriculum] Version and ecosystem synchronization — resolve stale version references and architecture diagrams #9)
• Adding new ecosystem content
• Rewriting lab exercises' business logic — only the result-handling pattern

Why this is P0

This issue changes the mental model the course teaches. Everything else — imports, versions, new content — builds on top of the architecture model. Without this fix, a student learns correct philosophy with an incorrect technical foundation, which is worse than learning neither.