fix(runtimed): unblock headless conda/uv kernels stuck on AwaitingTrust

[rgbkrk]

Found via headless gremlin runs against the latest nightly: any MCP create_notebook call that included a dep missing from the local allowlist parked the kernel at awaiting_trust forever. Headless callers (nightly gremlins, Claude Code) have no way to click through a trust dialog, so the notebook just sat there until the request timed out.

Three pieces of the fix.

Design decisions

Why numpy and scipy — both are foundational deps for any data persona, but neither was in the seed list. On my machine the gremlin's request for conda + [pandas, numpy, matplotlib] failed because the audit log showed every pypi:* user-approval over the past month but zero conda:* user-approvals — no one's ever clicked through a conda trust dialog, so conda:numpy never made it into the allowlist. Adding them to DEFAULT_DATA_PACKAGES seeds both ecosystems on daemon start. Pool envs already pulled numpy transitively via pandas/matplotlib, so the only meaningful install delta is scipy.

Why auto-trust on CreateNotebook deps — when an MCP tool call passes dependencies: ["pandas", ...] explicitly, the tool call itself is the consent event. The Claude Code UI (or whatever MCP host) approves the tool invocation; by the time bytes hit the daemon the caller has already opted in to those deps. OpenNotebook goes nowhere near this code — a downloaded notebook with a sketchy dep like canhazpassword still surfaces through the regular trust dialog.

Why a next_action hint instead of changing tool schemas — the existing manage_dependencies tool already accepts trust: true to grant approval. The gremlin didn't reach for it because the awaiting_trust response was a dead end. Surfacing the trust state + remediation hint in runtime.trust and runtime.next_action makes the available path visible to any caller looking at the response. Tool descriptions are untouched, so no tool-cache update needed.

Behavioral coverage

Scenario	Trust path	Outcome
create_notebook + explicit deps, no prior trust	seed via mcp_create_notebook	auto-launch
create_notebook + no deps	NoDependencies short-circuit, no seed	auto-launch
create_notebook + already-approved deps	seed is a no-op (ON CONFLICT DO NOTHING)	auto-launch
open_notebook of a downloaded .ipynb	unchanged, hits trust dialog	awaiting_trust until human approves
Any path that ends awaiting_trust	unchanged kernel state	response now includes runtime.trust + runtime.next_action pointing at manage_dependencies({trust: true})

Pool env impact

DEFAULT_DATA_PACKAGES participates in the pool-package hash (expected_pool_package_hash). The const change invalidates existing pool envs; next daemon start rebuilds them with the new list. numpy was already a transitive dep of pandas/matplotlib, so the practical install delta is scipy (~50MB per env).

Test plan

• cargo check -p runtimed -p runt-mcp
• cargo test -p runtimed --lib trusted_packages (10/10)
• cargo test -p runtimed --lib daemon (100/100)
• cargo test -p runtimed --lib notebook_sync_server (291/291, includes the two new auto-trust tests)
• cargo test -p runt-mcp --lib (120/120)
• Re-run the data-scientist gremlin against a daemon built from this branch and confirm conda + numpy launches without stalling.

Tests added

• test_seed_trust_from_doc_metadata_promotes_to_trusted — populates the doc with explicit deps, calls the helper, verifies the trust check now resolves to Trusted.
• test_seed_trust_from_doc_metadata_skips_when_no_deps — empty dep list short-circuits via NoDependencies and doesn't write phantom rows to the allowlist.

[pullfrog]

  ^{｜ Review this ➔}