docs: do not record how a machine's protection is configured

The host note said where Core.Tests can be built by describing one
machine's security configuration. A public repository is the wrong place
for that. The note now says only that Core.Tests is built where the owner
allows it, and that a quarantined build means stop and ask.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

CLAUDE.md

@@ -12,7 +12,7 @@ Policy lives in [AGENTS.md](AGENTS.md) (repository rules: hosting split, authori
 
 ## Commands
 
-**Host note first.** On the maintainer's development PC, Windows Defender's heuristics quarantine the compiled `Qqq.PrintAgent.Core.Tests` assembly. Since 2026-11-10 the owner excludes the development folder from scanning, so `Core.Tests` and `build/Verify.ps1` run locally inside it. A checkout outside that folder is still quarantined: there, build `Qqq.PrintAgent.NativeCI.slnx` (the full solution minus `Core.Tests`) and take Core evidence from hosted CI. Changing Defender settings is the owner's decision; if a `Core.Tests` build is quarantined again, stop and ask rather than adding an exclusion or restoring the file.
+**Host note first.** On some machines Windows Defender's heuristics quarantine the compiled `Qqq.PrintAgent.Core.Tests` assembly. Where the owner has said `Core.Tests` may be built, `build/Verify.ps1` runs in full. Anywhere else, build `Qqq.PrintAgent.NativeCI.slnx` (the full solution minus `Core.Tests`) and take Core evidence from CI. How a machine's protection is configured is the owner's decision and is not recorded in this repository: if a `Core.Tests` build is quarantined, stop and ask rather than adding an exclusion or restoring the file.
 
 Quick local loop without `Core.Tests` (locked restore, Release x64 build with `-warnaserror`, Windows/CLI tests), always with `-p:Platform=x64` because the solution maps test projects to AnyCPU and a direct `dotnet test` without it picks stale output. Never pass `--no-build` to `dotnet test`: the solution build writes the test DLL to the AnyCPU folder, so an x64 `--no-build` run executes whatever old x64 DLL is lying around and reports a pass against stale code.
 

docs/SESSION-STATE.md

@@ -8,7 +8,7 @@ Version 2.0 (several servers at once, a connection wizard, enforced quality gate
 - A second run of the same commit measured Windows at 68.91% (2,618 of 3,799): five lines in timing-dependent waits are not reached on every run.
 - The coverage gate now runs in `build/Verify.ps1` with minimums of 86 / 68 / 37 (Core / Windows / CLI) in `build/minimum-coverage.json`: the measured value rounded down, less one point for that variance. The release bar is 100 / 90 / 100, so the gate currently proves "within a point of the baseline", not "covered".
 - Not yet done: the standards exception records (90% Windows; Gitea equivalents) are unfiled, changed-line coverage is unmeasured, and Gitea runs no checks for this repository until its CI workflow lands (owned by the Gitea CI work, not this branch).
-- `Core.Tests` builds locally on the maintainer's PC since the owner excluded the development folder from Defender scanning on 2026-11-10; see the host note in `CLAUDE.md`. Earlier entries below that call Core.Tests hosted-only describe the state before that date.
+- Since 2026-11-10 the owner allows `Core.Tests` to be built on the maintainer's PC; see the host note in `CLAUDE.md`. Earlier entries below that call Core.Tests hosted-only describe the state before that date.
 - Stages: (1) foundations and gates, (2) runtime decomposition while still single-server, (3) multi-server service and versioned pipe, (4) view models, server tree and wizard, (5) release hardening and an independent re-audit.
 
 # Session state — 2026-11-06