Declare the served-rig stub's real (weightless) memory footprint

[Parad0x-Labs]

Root cause (the macOS CI stub-lane drop-out)

The reader/media served rigs register their loopback scripted provider with only input_modalities in manifest metadata. The capability truth then derives the stub's memory budget from its NAME: estimated_local_model_resident_gb('reader-drive:stub') falls back to the 8B default — 7.5 GB for a stub that carries no weights at all.

The router's ranking pass runs with enforce_hardware_fit=True (core/memory_first_router.py:5224), so on smaller-RAM hosts every pinned stub turn is hard-excluded as model_exceeds_hardware_budget — strict pass empty, relaxed pass empty (qwen3:4b also over budget), ranked_candidates: [], and the runtime answers selected_provider_excluded_before_invocation ("its provider lane is not available right now"). On a 24 GB dev Mac the bogus 7.5 GB still fits, which is why every local replica passed and only the runner failed.

Evidence chain (all on the runner, branch debug/macos-stub-lanes2)

• Decision-site dump: stub present, enabled, healthy, policy local-only False, default-request explain eligible — but the fit-enforced ranking recomputation returned []; is_text and turn_local_only both fine.
• estimated_local_model_resident_gb('reader-drive:stub') = 7.5 GB locally; declared ram_budget_gb: 0.5 fits even a simulated 6 GB mps host.
• A/B on the runner, same workflow, full macOS job file order: 20 failed / 92 passed before the one-line metadata declaration → 112 passed / 8 skipped / 0 failed after (run 35565884049).

Repair

tests/_reader_served_rig.py (the one seam behind artifact-readers m1/m2 and media-product-served): the registered manifest declares ram_budget_gb/vram_budget_gb of 0.5 — the truth for a weightless loopback stub — with a comment naming the estimator default and the measured runner loss. Local: the three suites 38 passed; ruff clean.

Contributed by sls_0x.