Closes construction - build and test across all seven units

Unit suites already passed individually; this is the full solution
together plus what none of them could check alone: two real hosts
talking to each other, a slave API key encrypted by one process and
decrypted by the next one after a restart, and headers landing on
actual static files instead of a simulated response.

aidlc-docs/features/gitea-deployment-workflow/construction/build-and-test/unit-test-instructions.md

@@ -0,0 +1,29 @@
+# Unit Test Execution
+
+## Run Unit Tests
+
+### 1. Execute All Unit Tests
+```powershell
+dotnet test SlpModularCms.sln -c Release
+
+cd frontend
+pnpm run test
+```
+
+### 2. Review Test Results
+- **Expected — backend**: 372 tests pass, 0 failures (Core 196, Availability 82, Master 57, Identity 37). `SlpModularCms.Api` and `SlpModularCms.Api.Slave` have no test project by convention (CLAUDE.md) — their behaviour is covered by this stage's live integration verification instead
+- **Expected — frontend**: 237 tests pass, 0 failures, across 38 test files
+- **Test Coverage**: no coverage threshold is enforced (D-10 — deliberate decision, not an oversight)
+- **Test Report Location**: console output; `dotnet test` and `vitest run` both exit non-zero on any failure, which is what the CI gates (U5) act on
+
+### 3. Fix Failing Tests
+If tests fail:
+1. Identify which project/file failed from the console output
+2. Since every unit was already build-and-test-verified individually during Code Generation, a failure here means a **cross-unit** interaction broke something that passed in isolation — check what changed in the units involved
+3. Fix and rerun until green
+
+## Result at This Stage (2026-07-28)
+
+- Backend: **372 passed, 0 failed**
+- Frontend: **237 passed, 0 failed**
+- Both counts are unchanged from the Round 2 and Round 3 per-unit baselines — confirms the full suite passes together, not just in isolation