feat(runtime): verify background HTTP readiness

[Dante-dan]

Summary

• add an opt-in, bounded HTTP health check for background Bash tasks, restricted to explicit loopback endpoints
• keep process lifecycle and endpoint readiness separate by projecting the spawned PID and structured checking, healthy, listening, or unreachable evidence
• refresh health evidence on Read while preserving existing behavior when no health check is declared
• honor the Host outbound privacy and proxy-credential admission policy before probing, while keeping an admitted loopback request local instead of sending it through a remote proxy

The runtime treats only a 2xx/3xx response as healthy. It reports non-success HTTP responses as listening, records safe connection/timeout/process-exit/policy causes for unreachable endpoints, follows no redirects, and never includes response bodies, provider error details, or proxy credentials.

The Host-policy admission boundary follows the direction in #5261. This PR retains the durable canonical manager contract, required native PID, and real process/SQLite lifecycle coverage.

Fixes #5237

Verification

• npm run build --workspace @maka/core
• npm run build --workspace @maka/storage
• npm run build --workspace @maka/runtime
• npm run build --workspace @maka/runtime-host
• npm run typecheck --workspace @maka/core
• npm run typecheck --workspace @maka/runtime
• npm run typecheck --workspace @maka/runtime-host
• npx biome check on the changed files
• 10 passing core shell-run result tests
• 6 passing focused manager tests, including real process/PID/SQLite persistence under privacy and missing-credential policies
• 6 passing runtime-host web-fetch tests, including credential-free authorization results

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex implemented the runtime contract, process-manager and Host-policy integration, and focused tests.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[me2seeks]

Automated review notice: This comment was posted by an automated review agent operated by me2seeks make. It is not an independent human review and does not replace one.

Summary

Adds verified readiness for background HTTP shell runs: ShellRunHttpHealthCheckRequest constrains probes to explicit loopback (host: '127.0.0.1' | '::1') with a 5s default/30s max timeout, the manager awaits initial health before reporting a background endpoint as ready, and the Host-side createHostLoopbackHealthAuthorizer routes each probe through current outbound policy — blocking on privacy_mode/credential_not_configured while deliberately carrying no proxy material (loopback stays local, documented in place). Probe/sleep/authorize are injectable for deterministic tests. The issue ("ready" claimed before anything listens, misread as namespace isolation) is real, and the loopback-only contract keeps the probe from becoming an SSRF-shaped surface. abortSignal is checked before and after policy resolution. CI test green.

Findings

1. [P3] parseShellRunHttpHealthCheck — verify the parser rejects non-loopback hosts (the type says it must, and tests should pin it); if a caller-supplied healthCheck URL could name an arbitrary host, the probe would let a background run health-check an internal endpoint on the Host's behalf. From the contract shape this appears closed, but the parse-time rejection is the one assertion that must exist.
2. [P3] The 30s worst-case await happens on the run-start path with retry sleeps; confirm the run's own abortSignal threads into waitForHealthRetry so a cancelled start doesn't linger the full timeout.

Verdict

merge-ready — loopback-constrained, policy-routed readiness at the right layer with honest "origin observed, page not claimed" framing; two P3 verifications only.