FABRIC-2.md: close Kconfig/menuconfig end-to-end item

Verified via tools/kconfig/conf + kernel_amd64_defconfig: a .config edit to CONFIG_SK_PARITY_DEBUG genuinely flows through to the parity.c compile line's -D flag in both directions. Required installing bison/flex, which were missing.

FABRIC-2.md

@@ -205,12 +205,32 @@ and recorded.
 - [ ] `bump-z`/`bump-y` Makefile targets reference `STARFORTH_VERSION_MAJOR`/`MINOR`/`PATCH`/
   `STARFORTH_VERSION_STRING` fields that don't exist in the actual generated
   `include/version.h` (also noted in `.claude/CLAUDE.md`).
-- [ ] **Kconfig/`menuconfig` has never been exercised end-to-end.** Every knob added so far
+- [x] **Kconfig/`menuconfig` has never been exercised end-to-end.** Every knob added so far
   (including item 4.1's `STADIUM_WORD_HEAT_QUANTUM`/`STADIUM_WORD_COOL_RATE_Q48`) has only
   ever been verified via its `Makefile.starkernel` default. Nobody has run
   `make -f Makefile.starkernel menuconfig`, changed a value, and confirmed it flows through
   to a build. Flagged by Captain Bob 2026-08-05.
 
+  > **DONE 2026-08-13.** The vendored `tools/kconfig` build had never actually succeeded on
+  > this machine — `bison`/`flex` were missing, installed with Captain Bob's go-ahead.
+  > `mconf` needs an interactive TTY this environment doesn't have, so the exercise used
+  > `conf` directly (same underlying engine `menuconfig` calls) rather than the ncurses
+  > frontend itself. `make -f Makefile.starkernel ARCH=amd64 kernel_amd64_defconfig`
+  > generated `build/amd64/.config` correctly (`CONFIG_SK_PARITY_DEBUG` unset, matching
+  > Kconfig's `default n`). Hand-editing that line to `CONFIG_SK_PARITY_DEBUG=y` and
+  > re-running the kernel build showed the real compile line for
+  > `src/starkernel/vm/parity.c` gained `-DSK_PARITY_DEBUG=1` (was `=0`), and the object
+  > compiled clean with it; reverting the line back to unset flipped the flag back to
+  > `=0`. Confirms the `mk/Kconfig.mk` bridge and `kconfig_bool` macro genuinely wire a
+  > `.config` change through to `-D` flags in both directions — this had never been
+  > verified before. One caveat found in passing, not itself a bug: invoking
+  > `tools/kconfig/conf` directly (bypassing the Makefile) writes a stray `.config` +
+  > `include/config/`/`include/generated/` at the repo root instead of under `build/`,
+  > since it doesn't pick up the `KCONFIG_CONFIG`/etc. env vars `mk/Kconfig.mk` exports —
+  > only matters if invoking `conf` by hand outside the Makefile targets, as done here;
+  > cleaned up before committing. No `.config`/`build/` artifacts committed — both are
+  > gitignored working state.
+
 ---
 
 ## D. Design questions still genuinely open