test(win): preserve native inherited-child DACL regression coverage

[zackees]

Context

Preserve native Windows regression coverage for the reproducible private-file DACL failure exposed by the original release-fix revision of #222. The failures below are historical: current main and the updated PR head already contain the subsequent Windows remediation. This issue does not assert that the old failure persists on either current revision.

The original test, platform_win::ipc_private_dir::tests::inherited_private_child_is_accepted_but_explicitly_permissive_child_is_rejected, failed at src/platform_win/ipc_private_dir.rs:494:79 during soldr cargo test --locked --all-features:

called `Result::unwrap()` on an `Err` value: Custom { kind: PermissionDenied,
error: "private input is not current-user owner/SYSTEM DACL private" }
test result: FAILED. 563 passed; 1 failed; 3 ignored

Three recorded executions show the same test, location, error, and result:

Revision / execution	Evidence
main fc634e507024d63ccaaf75fa564818b9dcfbff36, September 13	Run 34761015461, Windows job 103733741381
Original #222 revision 0f5722dc1d1429fd8a2deceb0114dc04618f70dd, September 13	Run 34780969049, attempt 1, job 103787793199
Dedicated retry of that same old #222 revision, September 14	Run 34780969049, attempt 2, job 104021803597

The baseline runner reported Windows Server 2025 10.0.26100, image windows-2025-vs2026 version 20260907.229.1, and Rust 1.95.0. The original release commit changed five release-workflow/CI-script files and no Windows IPC source. Its retry still tested the old SHA; it was not validation of updated main.

The original fixture and verifier were introduced by #207. The fixture hardened a directory, used ordinary fs::write to create an inheriting child, then tried to read it. It failed before reaching the second assertion that a World-readable child is rejected. The verifier separately required owner equality with TokenUser and byte equality with one of two Owner Rights/SYSTEM ACL encodings. The shared error does not identify which predicate failed. Windows assigns new-object ownership from the token's default owner, so creation alone does not establish the fixture's ownership assumption. See Microsoft's object-owner documentation.

Remediation already present; remaining coverage gap

#220 introduced current-user SID/SYSTEM policy validation and inherited-ACE handling, with a successful native Windows job. Its merge 8078ce8c95e55811ce3f359ac424340199f0e5c7 is an ancestor of current main; later Windows fixes are also present.

At investigation time, remote main was a8b53e26348d22d3abd0f0fae69c8a40470a934f and #222 head was aa3c8c99d721f048ad080fb4668c1a5a68557910. Both have the same ipc_private_dir.rs blob, 911c3f1b0a66ca558475c76ed1948a987147c362.

The current native test is now created_private_child_is_accepted_but_explicitly_permissive_child_is_rejected: it uses create_private_file, which explicitly assigns the current user's ownership and private DACL. That covers the production creator. The adjacent parser test checks synthetic inherited ACE bytes, but neither retains the original native fs::write inheritance scenario. The assertion message also still calls this directly secured file an "inherited child".

Proposal

1. Keep the existing production-creator test and add a separate native test for an ordinary file created with fs::write beneath ensure_owner_private_directory. Let Windows materialize the inherited DACL, then exercise read_private_regular_file_bounded on the file. Do not rewrite that child's ACL before the acceptance assertion.
2. Capture useful failure diagnostics from the opened object: current token user SID, actual owner SID, and DACL/ACE flags. Establish whether a failure concerns ownership, principals, access masks, or inheritance representation.
3. In that inherited-file fixture, independently prove that applying the explicitly permissive D:P(A;;GR;;;WD) policy results in PermissionDenied. Keep the existing direct-creator coverage and precise parser rejection policy.
4. Correct the direct-creator test's misleading "inherited child" diagnostic. Reuse the remediation already on main; change production code only if the new native reproduction demonstrates a remaining defect.

Acceptance criteria

• RED → GREEN evidence: retain the linked historical RED, reproduce the focused old test on fc634e5 or 0f5722d in native Windows before any further production fix, and record the environment and exact revision. On updated main, run the new real-inheritance fixture GREEN alongside the existing direct-creator fixture. If the new fixture already passes, record that honestly; do not introduce an artificial production failure.
• Native inherited children and files made by create_private_file both exercise the bounded-read API successfully under the documented current-user/SYSTEM policy; the inherited test confirms it actually observes inherited ACEs.
• The permissive child is rejected with PermissionDenied, and tests retain rejection of unintended principals/ACE forms rather than skipping or weakening security assertions to obtain green CI.
• Run both focused Windows tests and the full soldr cargo test --locked --all-features on the exact reviewed head. Attach native Windows results; compile-only cross-checks do not establish runtime ACL behavior.
• Report the commit SHA for the successful run so a retry of an obsolete fix(wasm): repair all-features build; close ConPTY manifest issue #222 revision cannot be mistaken for current-head evidence. Keep the Windows regression enabled and preserve the existing feature gates and facade boundary.

Focused historical reproduction:

soldr cargo test --locked --all-features --lib platform_win::ipc_private_dir::tests::inherited_private_child_is_accepted_but_explicitly_permissive_child_is_rejected -- --exact --nocapture

Decisions

• Scope: regression coverage and validation (P2). The recorded failure was a release-check blocker, but current main already contains remediation; there is no evidence here of an unresolved current-head failure.
• Separate direct creation from inherited creation. Both are meaningful paths, and the existing fixture changed which path it exercises.
• Reuse current policy. Do not replay feat: rebase application foundations onto kernal-api #220 or broaden accepted principals/rights based on historical logs. Any newly observed defect needs its own focused RED signal before a production change.
• Keep this Windows-local. No new backend exposure, dependencies, cross-platform HAL, or feature expansion is needed.
• Duplicate search: searched open and closed issues for DACL, owner-private, the failing test name, and the bounded-read API. No issue directly tracking this native inheritance coverage gap was found; broader IPC/facade issues are omitted.

Related work

• feat(fs): add bounded owner-private regular file reads #207 introduced the verifier and original regression test; its validation explicitly left native Windows execution outstanding.
• feat: rebase application foundations onto kernal-api #220 contains the prior remediation and successful native execution for this same failure.
• fix(wasm): repair all-features build; close ConPTY manifest issue #222 exposed the historical failure in a release-fix check; its updated head already includes the remediation.