fix(security): no VM but Artemis and Hera can make Hera run text; a message runs once; word-ACL elevation removed

Any identity could have arbitrary FORTH run as Zuse: KH-ELEVATE-SEND and
KH-BLK-ATTACH-SEND sent any text to Hera, from any VM (shown live).  And the
drain popped a message after running it, so a payload calling a colon word
ran twice.  Both fixed test first (FABRIC-3 SXXXVII):

- KH-BLK-ATTACH-SEND is ( dev-addr ok? -- sent? ), Artemis only; the kernel
  writes the reply text.  BLK-ATTACH-ACK is Hera's only.
- The drain pops before it runs.
- Elevation, ruled not needed: KH-ELEVATE-SEND, message type 8,
  zuse-eligibility.4th, ZUSE-ELIGIBLE?/ZUSE-ELIGIBILITY-ADD/
  ELEVATE-PUBKEY-UNPACK and the eligibility list removed; its disk area
  stays reserved, unused.  FABRIC-3.7 closed.

Three ISAs: POST 1052 passed; new parity baseline word_count=523
hash=0xb73b58052d591638 (deliberate).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kernel/include/starkernel/artemis_sig.h

@@ -63,10 +63,10 @@
  * "top-of-device, outside the user-addressable LBN pool" region
  * block_subsystem.c's own meta_fence_blocks reservation (128 devblocks by
  * default, BLK_META_FENCE_INIT) already carves out for exactly this kind
- * of system metadata, and where Zuse's own genesis marker/eligibility list
- * already live (blk_meta_zone_read()/write(), devblock_from_top 0 and 1+
- * respectively). This format deliberately does NOT go through
- * blk_meta_zone_*, though: that accessor requires the device to already be
+ * of system metadata, and where Zuse's own genesis marker already lives
+ * (blk_meta_zone_read()/write(), devblock_from_top 0; 1-63 reserved,
+ * unused, since the eligibility list was removed 2026-10-14). This
+ * format deliberately does NOT go through blk_meta_zone_*, though: that accessor requires the device to already be
  * blk_subsys_attach_device()'d and format-detected (first_disk_slot()) --
  * exactly the state generic pre-attach discovery (repl.c's idle-loop
  * USB-MSC scan) doesn't have yet, which is the entire reason this format
@@ -74,11 +74,8 @@
  * the same top-of-device arithmetic independently via blkio_info(), so
  * they work on a raw, not-yet-attached device exactly like
  * homeblocks_sig_check() already does. ARTEMIS_SIG_DEVBLOCK_FROM_TOP is
- * fixed well clear of Zuse's two tenants (0 and 1+, open-ended but
- * realistically small -- 127 pubkeys per chained devblock) so the two
- * subsystems' independent top-of-device math can never collide, without
- * this format needing to know how far the eligibility chain has actually
- * grown on any given boot.
+ * fixed well clear of Zuse's genesis marker (0) and the reserved,
+ * unused 1-63.
  *
  * Reserves offset/size pointers to the growable per-VM log-persistence
  * region (FABRIC-3.md §XXVI follow-on's own log-record work), the same way
@@ -123,11 +120,10 @@ extern "C" {
  * last devblock, 1 = second-to-last, ...), computed independently here via
  * blkio_info() rather than through that accessor (which needs an already-
  * attached, format-detected slot this code runs before). Fixed well past
- * Zuse's genesis marker (devblock_from_top 0) and eligibility list
- * (devblock_from_top 1, chained upward as needed) -- see
- * zuse_eligibility_list.h -- so the two subsystems' independent top-of-
- * device math can never collide regardless of how large the eligibility
- * chain grows in practice. Well inside BLK_META_FENCE_INIT (128 devblocks,
+ * Zuse's genesis marker (devblock_from_top 0) and devblock_from_top
+ * 1-63 -- once Zuse's eligibility list, reserved and unused since that
+ * list was removed with word-ACL elevation (2026-10-14, FABRIC-3.md
+ * SXXXVII) -- so nothing here can collide with what stood there. Well inside BLK_META_FENCE_INIT (128 devblocks,
  * block_subsystem.h) on any real Artemis disk. */
 #define ARTEMIS_SIG_DEVBLOCK_FROM_TOP 64u