§H.12 step 12: BMAPFMT field layout in blk_meta_t

Replaced the old 40-byte owner_id/permissions/acl_block/signature[2]
with owner_fp[8]/acl_allow/acl_ttl (u32)/acl_reserved[3]/reserved_future,
matching the decided §F.4/§H.6 layout.

Found a pre-existing bug via a real offsetof/sizeof compile check
(not hand math, per this step's own instruction): sizeof(blk_meta_t)
was already 344, not the 341 its own BLK_META_PER_BLOCK constant and
"341-byte slice" comment claimed -- harmless since that constant has
zero callers anywhere. New size after this edit's own alignment
padding is 336. Added a _Static_assert matching blk_volume_meta_t's
existing precedent, and fixed the stale comment to point at it.
BLK_META_PER_BLOCK itself untouched -- unused, out of scope.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

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

include/block_subsystem.h

@@ -223,11 +223,37 @@ typedef struct {
     uint64_t entropy[4]; /* 256-bit entropy/random seed */
     uint64_t hash[4]; /* SHA-256 (optional) */
 
-    /* Security & ownership (40 bytes) */
-    uint64_t owner_id; /* User/process ID */
-    uint64_t permissions; /* rwx-style permissions */
-    uint64_t acl_block; /* Block number containing ACL (0=none) */
-    uint64_t signature[2]; /* 128-bit signature */
+    /* Security & ownership -- FABRIC-3.md §F.4/§H.6/§H.12 step 12, decided
+     * 2026-08-27/2026-09-03: BMAPFMT repurposes this slot rather than
+     * building a separate on-drive block-map table (distributed
+     * ownership/ACL, travels with the block itself). Replaces the old
+     * owner_id/permissions/acl_block/signature[2] fields, which predated
+     * and directly conflicted with both the anti-POSIX principle and
+     * VMIdentity's pubkey-based model. Not the same 40-byte budget the
+     * old fields occupied -- natural alignment padding (uint32_t acl_ttl
+     * and uint64_t reserved_future each force a few bytes of compiler-
+     * inserted padding after the preceding uint8_t fields) makes this
+     * section's real footprint smaller; verified below via
+     * _Static_assert on the whole struct's actual sizeof(), not trusted
+     * by hand (see the blk_volume_meta_t padding-bug lesson this project
+     * already learned once). */
+    uint8_t  owner_fp[8];     /* truncated fingerprint of owner's VMIdentity
+                                * pubkey -- cheap per-block; full pubkey
+                                * resolves via the drive's own identity
+                                * record. */
+    uint8_t  acl_allow;       /* cached fast-deny bit, checked first --
+                                * vm.c:611-624's exact pattern, applied to a
+                                * block instead of a word. */
+    uint32_t acl_ttl;         /* countdown, same shape as DictEntry's
+                                * acl_ttl -- blocks support temporary
+                                * elevation too, same ACL-TTL-reuse
+                                * mechanism and Zuse-eligibility-list gating
+                                * as the word card (§H.5). */
+    uint8_t  acl_reserved[3]; /* still genuinely undecided -- deliberate
+                                * slack per "flexibility until we understand
+                                * the recipe," not a placeholder to fill
+                                * reflexively. */
+    uint64_t reserved_future; /* untouched budget, same reasoning. */
 
     /* Link/chain support (32 bytes) */
     uint64_t prev_block; /* Previous in chain (0=none) */
@@ -238,10 +264,29 @@ typedef struct {
     /* Application-specific (120 bytes) */
     uint64_t app_data[15]; /* 15×64-bit app-defined fields */
 
-    /* Padding to reach 341-byte slice */
-    uint8_t padding[5];
+    uint8_t padding[5]; /* trailing slack, unrelated to any exact size target --
+                          * the old "341-byte slice" comment here was already
+                          * inaccurate before FABRIC-3.md §H.12 step 12's edit
+                          * (sizeof(blk_meta_t) was 344, not 341, due to
+                          * ordinary trailing struct-alignment padding after
+                          * this array -- harmless since BLK_META_PER_BLOCK,
+                          * the only thing that constant would matter to, has
+                          * zero callers anywhere in this codebase). Verify
+                          * this struct's real size with the _Static_assert
+                          * below, not by re-deriving it from this comment. */
 } blk_meta_t;
 
+/* Verified via offsetof()/sizeof(), not trusted by hand -- see the
+ * blk_volume_meta_t padding-bug lesson this project already learned once
+ * (a hand-summed struct padding formula hid a real 4-byte alignment gap).
+ * 336, not the BLK_META_PER_BLOCK/"341-byte slice" figure this struct's
+ * own comments have long claimed -- that mismatch predates this assert and
+ * is harmless today (see padding[5]'s own comment above), but this assert
+ * now makes any future drift in either direction fail the build instead of
+ * silently mismatching a constant nothing currently checks against it. */
+_Static_assert(sizeof(blk_meta_t) == 336,
+               "blk_meta_t size changed -- update this assert and check BLK_META_PER_BLOCK");
+
 /* Error codes */
 enum {
     BLK_OK = 0,