Add capsules/sdk.4th: SDK v1.9.0 vocabulary + FENCE over the cookbook capsules

Loads turtle.4th and doe.4th, defines SDK-VERSION/SDK-HELP into an SDK
vocabulary, then calls FENCE once everything is loaded -- protecting the
base wordset and both cookbook capsules from FORGET. Kernel-only (EXEC
doesn't exist hosted), REPL-invoked via S" sdk.4th" EXEC, not part of
init.4th's boot sequence.

Verified before writing the capsule, not assumed: VOCABULARY/DEFINITIONS
does not actually scope word visibility in this interpreter -- vm_find_word
is a flat dictionary scan that never consults CONTEXT/CURRENT. Documented
plainly in the HOWTO so this isn't mistaken for namespace isolation later.

Block range 5109-5115 -- discovered along the way that user-block space is
capped at [2048, 5120) by mkcapsule, tighter than expected.

Verified: mkcapsule --lint clean, hosted-build trace runs SDK-HELP with
zero attributable VM errors, zero build warnings and identical 1012/0/0
POST results with matching dict_hash on all three kernel architectures.

HOWTO: docs/working/architecture/SDK-HOWTO-20260819.md

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-2.md

@@ -1802,3 +1802,36 @@ matching the new test count exactly), 0 failed, 0 errors; three-arch kernel boot
 (1012/0/0 on amd64/aarch64/riscv64), `dict_hash` matches exactly across all three (changed from
 the pre-`FENCE` baseline as expected — a new C word legitimately changes the dictionary hash;
 cross-arch agreement is what's being checked, not stability against the prior baseline).
+
+**`capsules/sdk.4th` written — the SDK capsule itself, done.** Block range `5109`–`5115` (clear
+of `turtle.4th`'s `5100`–`5108`; discovered along the way that user-block space is actually
+capped at `[2048, 5120)` by `mkcapsule`, tighter than the `4000+`/"5000s in practice" impression
+from earlier sessions — `turtle.4th` at `5100`–`5108` and `sdk.4th` at `5109`–`5115` together
+leave only 4 blocks of headroom before the hard ceiling). Loads `turtle.4th` and `doe.4th` via
+`EXEC` (confirming the kernel-only decision was necessary, not just cautious), defines `SDK-
+VERSION`/`SDK-HELP` into an `SDK` vocabulary, restores `FORTH DEFINITIONS`, then calls the new
+`FENCE` — protecting the base wordset, both cookbook capsules, and its own two words in one
+call. Verified before writing a line of the capsule, not assumed: whether `VOCABULARY`/
+`DEFINITIONS` actually scope word visibility in this interpreter. It does not — `vm_find_word`
+(the interpreter's primary dispatch) is a flat, first-character-bucketed scan that never
+consults `CONTEXT`/`CURRENT`; a word defined under a custom vocabulary remained globally
+callable immediately after switching back to `FORTH DEFINITIONS`, confirmed by direct hosted
+test before committing to the capsule's design. Documented plainly in the HOWTO so nobody
+later assumes `SDK DEFINITIONS` provides isolation it doesn't.
+
+Verified: `mkcapsule --lint` clean; hosted-build trace (`fabric.4th` core + `turtle.4th` +
+`doe.4th` + `sdk.4th`'s own blocks, its two `EXEC` lines stripped and the target capsules
+concatenated directly instead, since `EXEC` doesn't exist hosted) runs `SDK-HELP` correctly
+with zero VM errors attributable to any of this content; zero build warnings and identical
+`1012 passed / 0 failed / 0 errors` boot on all three kernel architectures, `dict_hash`
+unchanged from the pre-`sdk.4th` baseline on all three (expected — not autoloaded, so it cannot
+affect boot-time dictionary content). HOWTO: `docs/working/architecture/SDK-HOWTO-20260819.md`.
+Not yet driven interactively through a live REPL, same DoE-before-REPL practical limit as
+`turtle.4th`'s own still-open item.
+
+This closes the mechanism + capsule work for SDK v1.9.0 scoping. Still open, not decided here:
+the `1.5.4`→`1.9.0` version-string bump itself, and whether to verify `turtle.4th`'s actual
+rendering before treating either it or this SDK as release-ready — both are release-process
+decisions, not implementation work, and belong to the user's call per the same pattern used
+throughout this scoping (`AskUserQuestion` for the calls that are genuinely the user's, not
+inferred).