fix(capsule): install owner per-principal overlays before the run export (#1197, #1224)

[jvsteiner]

Linked Issue

Closes #1224. Refs #1197 — the residual run+recv publisher-identity semantics are now tracked in #1454.

Summary

A #[astrid::run] run-loop capsule drives its run export directly, so nothing installed the owner's per-principal overlays before run was entered — its env overlay, secret store, home://, and KV all sat at the neutral deny-all floor. Autonomous background writes misrouted to the neutral store (invisible to the owner's tool calls and lost on reload — #1197), and env/secret/home:// reads were denied (#1224). This installs the owner's context once, in the has_run path, before the run task is spawned.

Changes

• New testable HostState::install_run_loop_owner_context (host_state_invocation.rs), called in the has_run path before the run task spawns.
• Owner = ctx.principal (the load owner; default for a shared run-loop capsule) — used directly because self.owner_principal isn't recorded until after the spawn.
• caller_context left untouched, so an inbound ipc::recv still installs a per-publisher context and effective_principal() keeps resolving the owner for the loop's own work.
• Fail-closed preserved: install_principal_overlays clears every overlay to the neutral floor when the owner has no home / KV construction fails — no regression for home-less capsules.

Verification

• cargo test -p astrid-capsule — 576 passed, 0 failed.
• New regression run_loop_owner_context_installs_owner_overlay_not_neutral asserts the loop resolves effective_kv().namespace() to {owner}:capsule:{id} (+ its own secret store), never the neutral placeholder.
• clippy clean, rustfmt applied.

Scope note

Closes the autonomous run-loop case. The recv path still re-targets KV to the publisher per message, so a run + ipc::recv capsule's own storage after a recv resolves to the last publisher — that intended-behaviour decision is tracked in #1454 (#1197 stays open for it).

Checklist

• Linked to an issue
• CHANGELOG.md updated

[jvsteiner]

@joshuajbouw ready for review — run-loop capsules get their per-principal KV/env/secrets overlay before the guest run export (#1197, #1224).

[joshuajbouw]

Review outcome: technically worth advancing. The runtime, Windows, CodeQL, and CI jobs are green. Please update the PR body to the repository template headings (Linked Issue, Summary, Changes, Verification/Test Plan, Checklist) and add the required changelog entry; those are the remaining failing gates. The stated run + ipc::recv publisher-identity semantics should remain explicit or be covered by a follow-up issue.

[joshuajbouw]

Adversarial review against current main found that this PR's owner-overlay intent is correct, but the current hash-shared runtime identity makes the patch unsafe to merge as scoped.

The kernel deduplicates one mutable live runtime per verified WASM hash and constructs the first runtime under synthetic default. Installing KV, secrets, home, environment, profile, and budgets into that Store can therefore expose default authority to a capsule installed only for a non-default principal and to every other view of the same hash. “First installer owns it” would remain load-order- and restart-dependent.

Tracked as prerequisite #1486. That issue preserves content-addressed bytes and compilation while separating principal-resident Stores, instances, subscriptions, processes, health, and lifecycle by authority scope. It explicitly covers boot, live load, attach-existing-view, derived-agent spawn, reload/restart, unload/delete, stdio MCP, persistent processes, and system-resident services.

After #1486 lands, this PR should be rebased and retain its core change: install the established PrincipalResident(owner) overlays before calling the run export, with a non-default persistence/isolation regression.