Create private evidence directories safely on fsGroup volumes

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc

workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md

@@ -667,6 +667,24 @@ publication, owner service/namespace and exact peer admission, registration and
 real human/deployed binding, platform backup/restore and product acceptance.
 No cluster apply, native secret read, factory attempt or paid call occurred.
 
+2026-09-11 — **native probe exposed fsGroup startup incompatibility.**
+The native synthetic sender Job failed during private-store bootstrap, before
+any audit HTTP request. A filesystem regression reproduced the same refusal:
+Kubernetes fsGroup-style setgid volume roots cause `mkdir(0700)` to create a
+`2700` child, which the evidence store correctly refuses. `private_directory`
+now clears inherited setgid only on a directory this invocation just created,
+through a non-symlink directory descriptor. Unsafe existing directories keep
+their mode and remain refused. The private evidence contract stays 0700/0600.
+
+The new regression failed before the correction and passes after it; existing
+2700/2770 directories remain unchanged and refused. The available full suite
+passes 335 tests, with 39 optional checks skipped in this environment. The native
+sender probe will consume this exact helper from pinned source before image
+rebuild/publication. The previously built local image is superseded by this
+source correction and must not be published as the final service candidate.
+T08 stays progress for native acceptance and the existing deployment/human
+binding/recovery gates; no service cutover or human disposition occurred.
+
 ## Known risks
 
 - **T02 is a hard gate.** Writing the blueprint before the layer ruling risks