Remove the daily memory enqueue cap

[iamwavecut]

Summary

This removes the daily memory enqueue cap (MEMORY_MAX_DAILY_ENQUEUED_RUNS, default 2000). Since memory runs are enqueued hourly (#251), the cap ran out at about 04:00 UTC. After that, no chat hour got a run for the rest of the UTC day, and GPU2 sat idle. On 2026-10-12 the cap dropped 4,652 qualifying chat hours. The active-queue bound MEMORY_MAX_QUEUED_RUNS stays and is now the only enqueue limit.

Changes

• MemoryRunEnqueuePolicy loses max_daily_enqueued_runs. The enqueue capacity is max_queued_runs − active queue.
• Storage no longer counts the runs created since midnight; SQL_COUNT_BASE_MEMORY_RUNS_CREATED_SINCE is removed.
• Enqueue rollups: the daily_cap decision becomes queue_cap. The max_daily_enqueued_runs metric is dropped, and effective_daily_limit becomes effective_limit. The admin UI does not read these fields.
• Admin /admin/api/memory/runs drops policy.max_daily_enqueued_runs.
• Config, .env.example and the design spec no longer mention the cap. A leftover MEMORY_MAX_DAILY_ENQUEUED_RUNS in an env file is ignored.

Verification

• cargo fmt --all, cargo clippy --workspace --all-targets -- -D warnings: clean.
• cargo test -p openplotva-memory -p openplotva-storage -p openplotva-config -p openplotva-app --lib: 1,680 passed, 0 failed.
• The live storage test live_memory_runs_are_enqueued_through_the_last_complete_hour runs the changed enqueue and rollup SQL in CI.

Deployment effect

• The startup tick after the deploy scans the whole retention window. It enqueues the chat hours that the cap skipped, newest first, bounded by MEMORY_MAX_QUEUED_RUNS (5000 in production).
• After that, the hourly ticks keep up, and the 03:02 full scan catches anything a full queue left behind.
• GPU2 serves this work at background priority behind dialog fallbacks and user tools. On 2026-10-13 it took about 5 hours for 2,100 runs.

[github-actions]

	Messages
📖	Danger checked 7 changed file(s).

Generated by 🚫 dangerJS against 8049e72