docs(architecture): add diagrams and implementation playbook

Added three new documents with nine Mermaid diagrams to make the strangler
fig strategy visible:

- README: container topology diagram at the start, with the proxy entry point
  and three seams labelled
- docs/architecture.md: five diagrams tracing the exact implementation:
  - The four seams and who holds authority at each boundary
  - How by-id read goes through the resolver, but list-read bypasses it
  - Case lifecycle state machine (the strategy in one picture)
  - Take-ownership sequence with failure windows annotated
  - Write-through error round-trip showing zero validation logic crossed
- docs/playbook.md: how to apply this to a production system:
  - Write-path decision tree (five read/write patterns)
  - Cutover ordering diagram (side-effects-free first, least recoverable last)
  - Seven transferable rules with pointers to the files that demonstrate them
  - Scope diagram of what's proven vs. left as your decisions

Resolved all 13 dangling § citations (to an absent spec doc) by linking to
the actual files or dropping them. Replaced portal-frontend/README.md
boilerplate with accurate content. All diagrams parse and link-check clean.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

new/src/New.Api/Seeding/OwnedApplicationSeeder.cs

@@ -11,7 +11,8 @@ namespace New.Api.Seeding;
 /// REG-2026-0001..0005 (fixed, deterministic ids so the smoke script and
 /// README click-through can reference them directly). REG-2026-0002 is
 /// seeded with an open case-framework task on purpose, so a later closure
-/// request against it demonstrates the §6 conflict (409, decision stands).
+/// request against it demonstrates the seam-D conflict (409, decision stands
+/// - see docs/adr/ADR-001-decision-independent-of-closure.md).
 /// </summary>
 internal static class OwnedApplicationSeeder
 {

new/tests/Architecture.Tests/ArchitectureTests.cs

@@ -9,7 +9,7 @@ using Xunit;
 namespace Architecture.Tests;
 
 /// <summary>
-/// Encodes §10's architecture rules as build-failing assertions. A demo that
+/// Encodes the design's architecture rules as build-failing assertions. A demo that
 /// passes the smoke script but fails these has demonstrated nothing - the
 /// seam boundaries are the point, not an implementation detail.
 /// </summary>
@@ -70,7 +70,7 @@ public class ArchitectureTests
     [Fact]
     public void Rule5_No_Legacy_Or_CaseFramework_Connection_String_In_New_Config()
     {
-        // Config-file concern, not code - see §10. Verified by inspection: the
+        // Config-file concern, not code. Verified by inspection: the
         // only connection string anywhere under New.* is ConnectionStrings:New
         // (New.Infrastructure.Persistence.ServiceCollectionExtensions), and
         // docker-compose.yml only ever injects ConnectionStrings__New into