feat(random): bounded secure OS entropy for application tokens

[zackees]

Refs #180 and #155. Depends on #179. Coordinated with FastLED/cli#242. This PR is stacked on the registry release fix; merge that first, then retarget this PR to main.

Changes

• Opt-in secure-random capability reuses the existing exact private getrandom backend without enabling crash/profiling.
• SecureRandom shares bounded native-work permits; requests are capped at 64 KiB and return semantic errors without partial output or insecure fallback.
• Caller deadlines and dropped futures retain admission until native work actually ends. Documentation distinguishes caller cancellation from interruption of a blocking OS call.
• Generic success/failure/cancellation/timeout tests live upstream; feature-isolation checks and native CI cover the capability. Token length, encoding and authorization remain application policy.

Validation

• RED: focused feature test failed because secure-random did not exist.
• GREEN: five focused tests (including real OS entropy smoke), full secure-random Rust test suite, strict all-target Clippy, formatting, and dependency-isolation checks pass locally.
• Single-reviewer pre-push review clean; reviewer independently reran all five focused tests.
• Native cross-platform CI and exact published FastLED adoption remain pending. No statistical randomness proof or measured build-speed gain is claimed.

[zackees]

The entropy-enabled registry package also verifies successfully: soldr cargo package --locked --features secure-random -j1 exited 0 after compiling the extracted artifact. FastLED adoption is in progress: its direct dependency boundary went RED then GREEN, and the 259-test Rust workspace suite passed with the kernel capability while preserving the 32-byte lowercase-hex token format. Final app lint is still running; this is local path-patch adoption, not publication.

[zackees]

Holding merge: CI run 34746633118 completed with a native Windows isolation proof failure, despite the same proof passing release-fix PR #179. The binary launched successfully, then returned OS 10053 ConnectionAborted after about five seconds. Source inspection shows lifecycle close follows load completion independently of the page isolation fetch/report; this is a possible harness race, not yet a proven cause. No security failure is being waived and no rerun has been substituted for investigation. All other jobs passed except policy-skipped native macOS tests.

[zackees]

Additional source detail: the page uses synchronous XMLHttpRequest, not an asynchronous fetch, so an ordinary DOM-load-before-fetch race is not established. The harness also assumes the first two accepted sockets are the document and report and emits uncontextualized socket errors; speculative browser connections or the report response write need to be distinguished. Investigation must preserve positive verification of the actual isolation report.

[zackees]

Pushed diagnostic-only commit 3da9bdb: socket errors now identify document/report accept, read or response-write stages while preserving error kinds, original native messages, deadlines and strict isolation assertions. Focused smoke-binary diagnostic test, strict Clippy and formatting pass locally; same release/viewer reviewer confirmed no security proof is weakened. New Windows CI will distinguish the previously uncontextualized OS10053 failure. This is instrumentation, not a claimed fix.

[zackees]

Diagnostic run34747510512 completed with the failure localized to write document response (OS10053 ConnectionAborted), before isolation-report validation. The harness currently treats read returning zero bytes as a document request and assumes accepted socket order. Next fix/repro will distinguish empty/speculative connections from a real bounded HTTP document request while retaining mandatory positive isolation-report verification; no merge or security waiver is being applied.

[zackees]

Pushed 48c23f3 to address a concrete proof-harness flaw: a zero-byte speculative connection was treated as the document request. The harness now skips empty connections within a shared 60-second deadline and 16-connection per-stage limit, requires complete headers within 4 KiB, and still fails on partial requests, response-write errors, or any missing/negative isolation report. The original Windows OS 10053 cause remains a hypothesis until native CI validates this change.

Validation: focused RED before implementation, four smoke-harness tests GREEN, strict Clippy and formatting PASS, existing reviewer found no blocking issues, and all six real Linux Xvfb proofs PASS (close, redirect, timeout, cancellation, native window close, and user-activated popup denial). A cargo-run rebuild was terminated by SIGTERM before proof execution; the already successfully built updated binary then passed all six scenarios directly. No production webview policy was weakened and no Safari validation is claimed.

The Windows lane on stacked PR #185 also failed in the native isolation proof with OS 10053; it should consume this fix after the prerequisite PR lands.

[zackees]

Native Windows validation of 48c23f3 is now green: both external-page isolation steps and the complete Windows job passed in run 34748635445. The overall attempt failed only because python(3.13) and each-feature(daemon-frame-v1) never acquired a runner (GitHub annotations say five attempts). Reran failed jobs only; attempt 2 is in progress. No source change or policy weakening was needed for these infrastructure failures.