[5db9054b] Bound the in-memory learning notification queue in learning.py (cap growth; optional prune-on-ack)

[roboco-app]

VERIFIED INTAKE FACTS (forwarded from upstream; anchors re-verified by be-pm on this branch, all current):

• Every recorded learning writes its notifications twice: once as DB rows via _persist_notifications (roboco/services/learning.py:315, bulk-inserts NotificationTable rows), and once as in-memory LearningNotification objects appended by _enqueue_in_memory (learning.py:292-304), one entry per notified agent. Queue init: learning.py:110 (self._notification_queue: list[LearningNotification] = []). Readers: get_pending_notifications (learning.py:458) only filters; acknowledge_notification (learning.py:479-494) only flips an acknowledged flag. Nothing is ever removed, so the queue grows monotonically in the orchestrator process until restart, one entry per notified agent per learning.
• The in-memory copy has no production reader: repo-wide grep shows zero callers of get_pending_notifications / acknowledge_notification outside the module (be-pm re-verified on this branch). The notifications API acks through NotificationDeliveryService instead — roboco/api/routes/notifications.py:107 acknowledge_for_recipient merely shares the method name and does NOT touch this service. Consequence: nothing in production ever acks, so a prune-on-ack-ONLY fix would prune nothing and the queue still grows — that is why the fix direction is BOUND.
• The original CELL-scope org-wide fanout headline is ALREADY FIXED on master (commit 04eb61d, PR [9efb36e4] CELL-scoped learning notifications bypass team filter — notify all agents #914): _fetch_notify_agents (learning.py:245-272) filters CELL scope to the author's team. Do NOT touch that logic.

DESIGN CALL (made by be-pm, recorded in the cell decision journal): BOUND the queue — a deque with maxlen, or cap+trim in _enqueue_in_memory, so appends beyond the cap evict the OLDEST entries. You MAY additionally prune acknowledged entries inside acknowledge_notification (cheap honesty for the public API). Queue REMOVAL is ruled out this round: tests/integration/test_learning_service.py still reads svc._notification_queue in 8 other places outside your scope (a sibling leaf owns that file in parallel) — removal would break its tests. Evicting oldest pending entries is safe: the NotificationTable rows from _persist_notifications remain the durable record, and nothing in production reads the in-memory queue.

HARD CONSTRAINTS:

• Never modify _fetch_notify_agents scope/selection logic (learning.py:245-272): TEAM (same role) and ORG (all non-human agents) fanout behavior must be unchanged.
• Do NOT touch tests/integration/test_learning_service.py (sibling leaf be-dev-1 owns it in parallel; the file-disjoint split is the point). Your queue-lifecycle coverage goes in the UNIT tree: tests/unit/services/test_learning.py already stubs OptimalService and imports LearningPropagationService / LearningNotification — extend it or add a sibling unit file under tests/unit/services/.
• Keep the public surface stable: get_pending_notifications / acknowledge_notification keep their signatures. If you switch list to deque, adjust the two readers (they only filter/iterate). Check whether anything imports LearningNotification or the queue type before changing it.
• Changes confined to roboco/services/learning.py and unit tests under tests/unit/services/. Run make quality via the Makefile (never raw uv run) — must be green before i_am_done.

[github-actions]

Thanks for opening your first pull request on RoboCo!

Quick checklist before review (most of these are enforced by CI, but worth a glance):

• make quality — ruff format check, ruff check, mypy, pytest (≥80% coverage), and the rest of the gate
• Panel changes pass pnpm lint and pnpm exec tsc --noEmit (run from panel/)
• No # noqa / # type: ignore shortcuts; pre-existing violations in touched files are fixed
• Added an entry under ## [Unreleased] in CHANGELOG.md
• Signed the CLA (the bot will prompt you on this PR)
• Signed your commits — master requires verified signatures (SSH signing setup)
• Updated any affected docs under docs/

See CONTRIBUTING.md for the full workflow and the Code of Conduct for the community standards we follow.

Welcome aboard — a maintainer will review shortly.