FABRIC-3.md: version correction -- LITHOS_VERSION back to 2.0.0, plus a rename-gap fix

LITHOS_VERSION 2.0.1 was premature: per this project's own versioning
policy, 2.0.1 claims SER5 hardware-track progress (RDRAND backend +
thumbdrive image) that was never actually verified on real hardware --
that verification is FABRIC-3.md's own open topic. Reset to 2.0.0
(still a QEMU-only release, correctly). Verified 3-arch boot shows
"LithosAnanke v2.0.0" in each serial log directly, not assumed from the
Makefile edit alone.

Also closes a real gap found in today's earlier FABRIC-series rename:
Makefile.starkernel, Kconfig.kernel, scripts/bleach_zuse_img.sh, four
proof/*.thy files, and isr.S were never swept -- the original file list
only matched *.md/*.c/*.h/*.4th, silently skipping every other
extension. Fixed with the same safe placeholder substitution.
.claude/settings.local.json's historical permission-grant log and
ClaudeEXPORT/'s frozen export were deliberately left untouched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var

FABRIC-3.md

@@ -76,3 +76,44 @@ starting new work avoids ever having two divergent lines to reconcile later.
 **Task 1 closed.** `master` genuinely is the production line again, current through today's
 FABRIC-series rename and the full `FABRIC-2.md` §I closure. Bare-metal-boot work (this
 document's actual topic) starts from here.
+
+## I.2 — Task 2: version correction — the `v2.0.1` bump and `v2.0.0` tag were premature
+
+**Direct instruction, 2026-09-04**: the `LITHOS_VERSION` bump to `2.0.1` (and the branch name
+that followed it) got ahead of the real state — per `Makefile.starkernel`'s own versioning
+policy (`v2.0.0` = QEMU release, even major/LTS; `v2.0.1` = the SER5 hardware-track *line*,
+RDRAND backend + thumbdrive image goal), claiming `2.0.1` implies hardware-track progress that
+was never actually verified on real hardware — that verification is precisely `FABRIC-3.md`'s
+whole open topic (§I.6 in the closed `FABRIC-2.md`). The current `master` HEAD is, correctly,
+still a `v2.0.0`-class QEMU-only release. "Nothing harmful" — a version-label correction, not a
+functional rollback.
+
+**Found and fixed while correcting this, not left half-done:**
+- A real gap in the FABRIC-series rename from earlier today: `Makefile.starkernel`,
+  `Kconfig.kernel`, `scripts/bleach_zuse_img.sh`, four `proof/*.thy` files, and
+  `src/starkernel/arch/amd64/isr.S` all still had stale `FABRIC.md`/`FABRIC-2.md`/`FABRIC-3.md`
+  citations — the original sweep's file-list only matched `--include=*.md/*.c/*.h/*.4th`, which
+  silently skipped every file without one of those four extensions. Found by re-grepping with
+  the extensions excluded instead of included. Fixed with the same safe placeholder-substitution
+  technique the original rename used (each file, one pass, ordered `FABRIC-3→2→1→0` placeholders
+  then resolved) — verified no double-shifted or broken references remained afterward.
+  `.claude/settings.local.json`'s own historical Bash-permission-grant log (literal past command
+  strings naming the file as it was called *at the time*) was deliberately left alone — rewriting
+  it would falsify an audit trail, not fix a stale citation.
+- `ClaudeEXPORT/memories.json`/`conversations.json` also still reference the old names — left
+  untouched on purpose, same reasoning as the memory note on that archive: it's a frozen export,
+  mining material, not live documentation to keep in sync.
+
+**Changes:**
+1. `Makefile.starkernel`: `LITHOS_VERSION ?= 2.0.1` → `2.0.0`.
+2. The rename-gap fix above (7 files).
+3. Verified 3-arch boot (`clean qemu`, amd64/aarch64/riscv64, each in the foreground): all three
+   show `LithosAnanke v2.0.0` in the boot banner (confirmed directly in each serial log, not
+   assumed from the Makefile edit alone), zero build errors, zero unexpected warnings, clean
+   shutdown.
+4. Moved the existing `v2.0.0` git tag (previously at `2efd7fe`, the original QEMU-release
+   milestone commit — that commit and its own message stay fully intact in history, only the
+   tag pointer moves) to the current `master`/`v2.0.1`-branch HEAD, per explicit instruction —
+   the prior tag placement was itself part of the same "got ahead of myself" correction, not a
+   separate decision. No remote tag existed yet (`git ls-remote --tags origin` was empty for
+   `v2.0.0`), so no destructive remote operation was needed, only a local move-and-push.