pkgs/id: 5 lib tests failing on main block the NixOS system build (rusqlite guard, fuel budgets, world_ws Screen drift) #3160

Summary

Five pkgs/id lib tests fail on current main. Because the NixOS system toplevel depends on the id service (id-web package → unit-id-primary.service → system-units → etc → toplevel), these failures gate nix build of the whole system and are currently blocking a deploy. Verified against the failed build log on the laptop (/nix/var/log/nix/drvs/d7/9c2azdf6l2km1gb0n3yzb9qqwh9s87-id-0.1.0.drv.bz2): 1958 passed; 5 failed; 6 ignored.

Drew has ruled: fix the tests properly — no check-phase exclusions.

The 5 failures, by root cause

1. The no-SQLite guard vs the dev-only rusqlite dependency

store_traits::tests::test_the_lock_has_no_sqlite_with_logsync_wired (src/store_traits.rs)

Cargo.lock names rusqlite: SQLite is back in the build (see vendor/README.md)

The guard (added 2026-10-12, fedb164, with the vendored p2panda-sync) asserts the raw Cargo.lock text names none of sqlx/sqlite/rusqlite/libsqlite3-sys: p2panda-sync's store dependency defaults to SQLite via sqlx, the vendored copy turns that default off, and the shipped store is redb. On 2026-10-30, b3421ef (#2276, bridge sync PoC) added rusqlite 0.32 (bundled) as a dev-dependency — SQLite for the PoC's DO-shaped hosted store, used by dev targets only, never shipped. A raw lockfile scan cannot tell a dev-only edge from a shipped one, so the guard now false-fires.

Fix: make the guard inspect the resolved dependency graph instead of the raw lock text — a SQLite-family package is acceptable only when every package that depends on it is either another SQLite-family package or this package itself, and this package's manifest must declare SQLite names only under dev-dependencies. The guard keeps its teeth (it still fails if rusqlite enters the shipped graph through any other dependent, or if the manifest moves it out of dev-dependencies) and keeps the p2panda-sync presence + vendored p2panda-store default-features = false assertions. The PoC stays.

2. Fuel budgets left stale by the pf.Screen migration

sandbox::tests::checked_in_examples_stay_within_fuel_budgets (src/sandbox.rs)

roc-counter view: used 260269 fuel, budget 100000
roc-counter layout: used 323425 fuel, budget 100000

commands::world::tests::measure_reports_fuel_per_call_kind_for_a_checked_in_module (src/commands/world.rs)

assertion failed: report["worst_call_percent_of_limit"].as_f64().unwrap() < 1.0

720eb57 (#565) migrated roc-counter to render through pf.Screen (boxed 20x3 screen) instead of a bare text view. Rendering a structured screen genuinely costs more wasmtime fuel than returning a string; the checked-in budgets were never re-baselined (old View/Layout baselines were 1,327/1,337). The sandbox test's own failure message prescribes the fix: "re-baseline deliberately: update the table and say why in the commit."

Fix: regenerate the roc-counter baselines/budgets with the shipped print_fuel_baseline generator (rule: baseline +25%, rounded up to the next 100,000 → View 400,000 on baseline 260,269; Layout 500,000 on baseline 323,425). The measure test does not read the table — it has its own bound (worst call < 1% of the 10,000,000 fuel limit, i.e. < 100,000 fuel, the same stale assumption). Update it consistently with the re-baselined envelope: the worst roc-counter call is now Layout at 323,425 (3.23%), and the largest per-call budget the table allows this module is 500,000 (5%), so the assertion becomes worst_call_percent_of_limit < 5.0 with a comment tying it to the budget table.

3. world_ws tests vs the Screen capability model

web::world_ws::tests::browser_websocket_can_compile_install_and_run_roc_sources (src/web/world_ws.rs)

compile failed: main.roc imports Screen, which this world does not allow
(grant it with `id world caps --grant Screen`; a capability ceiling may also exclude it)

examples/roc-counter/main.roc now imports pf.Screen, but the test world is a fresh WorldCore whose capability ledger has granted nothing, so the compile gate (world_compile::check_imports against the ledger's effective list) correctly refuses. Fix: grant the Screen capability to the test world (world.update_caps) before compiling — the same admin path the product exposes — not by weakening the ceiling check.

web::world_ws::tests::browser_websocket_can_upload_and_run_a_roc_module (src/web/world_ws.rs)

left:  "{\"kind\":\"screen\",\"version\":1,\"width\":20,\"height\":3,\"rows\":[\"+-counter----------+\",\"| count=0          |\",\"+------------------+\"]}"
right: "count=0"

The module's view now returns a screen frame instead of bare text. Fix: update the snapshot/event expectations to the screen frame and assert the count row content (count=0, then count=1 after the inc input).

Verification

• cargo test (release, lib): the 5 named tests, then the full lib suite.
• nix build .#id-web from the repo root flake (the package the system consumes) — check phase must pass end to end.

Acceptance criteria

• All five named lib tests pass on current main (store_traits no-SQLite guard, and the remaining four grouped in the issue body), with the pkgs/id suite back to 0 failures.
• The no-SQLite guard still fails when a SQLite-family package enters the shipped (non-dev) dependency graph — the graph-based guard keeps its teeth, per the issue's fix direction.
• nix build of the id package / NixOS system toplevel passes the check phase with no check-phase exclusions (Drew's ruling in the issue).