fix(lr-0827ba): make rate-limit auto-schedule arming state per-session

[clagentic-builder]

Fixes lr-0827ba / GitHub issue #328: rate-limit auto-schedule arming state was global to the browser tab instead of per-session.

Root cause

• lib/public/modules/input.js: scheduleDelayMs was a single bare module-scoped variable, consumed in sendMessage().
• lib/public/modules/app-rate-limit.js: handleRateLimitEvent() called setScheduleDelayMs() to auto-arm on rejection. Related state (rateLimitResetsAt, rateLimitResetTimer, rateLimitResetState, scheduled-message-bubble text) was also bare module-scoped.
• Because the SPA never reloads the page on project switch, all sessions across all projects shared this one set of variables. Arming a schedule in project B silently clobbered project A armed state.
• resetRateLimitState(), called on every project/session switch, also nulled out the OUTGOING session reset timer and armed delay, canceling in-progress background arming instead of leaving it running -- unlike the already-correct server-side session.scheduledMessage in lib/project.js.
• WS payloads for rate_limit / rate_limit_usage / scheduled_message_queued / scheduled_message_sent / scheduled_message_cancelled carried no session-identifying field, so a client had no way to correlate an incoming event with the session it actually belongs to.

Fix

1. New lib/public/modules/rate-limit-state.js: a DOM-free per-session state map keyed by session localId (mirrors the existing sessionDrafts precedent), covering schedule-delay arming, rate-limit reset bookkeeping, and the scheduled-message-bubble text/resetsAt.
2. input.js and app-rate-limit.js now read/write through this module instead of bare variables. Each session background reset timer keeps running even when unfocused, mirroring server-side session.scheduledMessage.
3. Server-side (lib/project.js, lib/sdk-message-processor.js): scheduled_message_queued/sent/cancelled and rate_limit/rate_limit_usage payloads are now stamped with localId: session.localId so the client can route/correlate events to the correct session.
4. app-messages.js session_switched now calls restoreRateLimitStateForSession() after resetClientState() -- the redraw-on-switch-in hook -- to restore the incoming session own armed/queued state instead of relying on the previous unreliable chat-history-replay side effect.

Trade-off (named, not silently shipped)

forgetSessionRateLimitState()/clearSession() exist in rate-limit-state.js for pruning a session state when it is actually deleted (not merely switched away from), but are not wired into the delete_session flow here. renderSessionList() only receives the current project session list, so pruning there risks cross-project ambiguity, and the existing sessionDrafts map (the established per-session-state precedent) has the same never-pruned-on-delete gap already. Flagging here rather than guessing at a wiring point outside this task scope.

Tests

• test/rate-limit-state.test.js: per-session isolation of armed state (arm in session A, arm in session B, both survive), clearSession teardown including canceling the background timer, scheduled-message-bubble isolation, session-id keying edge cases.
• test/rate-limit-per-session-lr-0827ba.test.js: source-text regression tests (matching the existing frontend-state-correlation-lr-fb49.test.js convention for DOM/live-server coupled modules) covering server-side localId stamping, client-side msg.localId routing, and the switch-in redraw ordering.

npm test: 950 tests, 947 pass, 3 fail. The 3 failures are pre-existing and unrelated to this change -- all three are in test/sdk-bridge-context-window-warn.test.js (lr-1f7e cases 1, 3, 10), confirmed to fail identically on unmodified origin/main via a throwaway git worktree comparison before this diff was applied.

lr-0827ba
Closes #328

[clagentic-reviewer]

PEACHES — blocking

Session cleanup gap: forgetSessionRateLimitState() is implemented but never called when a session is deleted. This causes per-session rate-limit state entries and their background reset timers (setTimeout) to leak indefinitely, accumulating memory over time as sessions are created/deleted.

Details:

• lib/public/modules/app-rate-limit.js:608 defines forgetSessionRateLimitState() with correct intent ("Call when a session is actually destroyed/removed") but the function is never wired into the delete_session flow.
• When sidebar-sessions.js:237 sends delete_session to the server, no corresponding client-side cleanup of rate-limit-state.js:_bySession[sessionId] occurs.
• rate-limit-state.js:121 shows the design is sound (calls clearTimeout on the timer), but the entry is never removed.
• This repeats the same gap as sessionDrafts (app-messages.js:518) which also leaks on session deletion.
• Impact: 100 deleted sessions → 100 orphaned timers/state entries leaking in browser memory. On mobile/resource-constrained devices, degrades performance over time until refresh.

Mitigation: Call forgetSessionRateLimitState(sessionId) when the server confirms session deletion (likely via new session_deleted message or by cleanup in sidebar-sessions.js immediately after delete_session send with server confirmation).

{"reviewer": "peaches", "review_status": "blocking", "head_sha": "b76bf927ec7df08564b39ff211ef0cf9d01e9aee", "pr_number": 340}

[clagentic-reviewer]

PEACHES — clean (0 nits)

Re-review of PR #340 (lr-0827ba / issue #328) — the blocking finding from the prior review has been fully resolved.

Prior Finding (Blocking): forgetSessionRateLimitState() was implemented but never called on session deletion, causing memory/timer leaks (orphaned reset timers and per-session state entries).

Fix Verification:

1. All three session-deletion paths now broadcast session_deleted:

   • lib/sessions.js:1058 — deleteSession() calls broadcastSessionDeleted(localId)
   • lib/sessions.js:1121 — deleteSessionsBulk() calls broadcastSessionDeleted(ids)
   • lib/project-loop.js:1447 — delete_loop_group handler calls sm.broadcastSessionDeleted(sessionIds)

2. Client dispatch wired correctly:

   • lib/public/modules/app-messages.js:438–448 — new session_deleted case iterates over msg.ids and calls forgetSessionRateLimitState(deletedId) for each
   • app-rate-limit.js:610–612 — forgetSessionRateLimitState() delegates to clearSessionRateLimitState (alias to rate-limit-state.js's clearSession)

3. Cleanup logic cancels timer and deletes entry:

   • lib/public/modules/rate-limit-state.js:118–123 — clearSession() checks for and calls clearTimeout() on the background reset timer, then deletes the entry from the per-session state map

4. Comprehensive regression tests:

   • test/rate-limit-state.test.js — unit tests verifying per-session isolation and timer cancellation
   • test/rate-limit-per-session-lr-0827ba.test.js — source-text checks for server-side localId stamps and client dispatch routing
   • test/session-deleted-rate-limit-cleanup-lr-0827ba.test.js — end-to-end verification that all three deletion paths broadcast, client receives/dispatches, and cleanup runs

No new issues detected. Code follows AMoS craft rules, no hardcoded paths, no brand violations, client/server layer boundaries respected.

{"reviewer": "peaches", "review_status": "clean", "head_sha": "2ecd9160536405b51f9f029d869268503d2ec9bc", "pr_number": 340}

[clagentic-security]

BOBBIE -- clean

Audited PR #340 (lr-0827ba / issue #328, head 2ecd916) -- per-session rate-limit auto-schedule arming state, plus the new session_deleted WS broadcast and localId stamping on scheduled-message/rate-limit payloads.

Findings: none blocking, none nit.

Scope verified: 11 files, +840/-50 (matches assignment), diffed base 3f25c02..head 2ecd916.

Reasoning on the flagged surface:

• session_deleted (lib/sessions.js broadcastSessionDeleted, lib/project-loop.js delete_loop_group) broadcasts only server-assigned integer localIds via the same send() broadcast path already used by session_list -- no new info-leak (ids already visible via session_list), no injection (ids are never attacker-supplied strings echoed back, only sessions.get() keys), no cross-session-routing exposure (client-side forgetSessionRateLimitState only deletes the client's own local per-session map entry).
• localId stamping (lib/project.js, lib/sdk-message-processor.js) is a server-authoritative field derived from session.localId, not from client input -- no forgery vector introduced.
• Client-side rate-limit-state.js keys its per-session map with Object.create(null) (no prototype), so numeric/string localId keys cannot trigger prototype pollution.

Scanner results:

• gitleaks detect (log-opts 3f25c02..2ecd916): no leaks found.
• trufflehog: unavailable in this environment (binary not found) -- recorded as scanner_status, judgment-only for secrets beyond gitleaks.
• semgrep --config auto (8 changed lib/ files): 11 findings, all in lib/project.js at lines 38/52/101/116/130/243/258/785/1168/1231 -- all outside the base..head diff hunks (PR only touches project.js lines 689-720). Dropped as pre-existing, out of scope per Pre-Report Gate rule 1.
• osv-scanner (package-lock.json): 46 pre-existing vulnerabilities across 17 packages, but package.json/package-lock.json has zero diff in this PR (dep manifest untouched) -- not introduced by this PR, dropped as out of scope.

No rulebook-citable findings within the base..head diff.

scanners_run: gitleaks (ok), semgrep (ok), osv-scanner (ok, no-diff-in-scope), trufflehog (unavailable)

• N/A -- no findings

{"reviewer": "bobbie", "review_status": "clean", "head_sha": "2ecd9160536405b51f9f029d869268503d2ec9bc", "pr_number": 340}

[clagentic-merger]

Merged via clagentic-loadout v0.1.0

• Gated HEAD SHA: 2ecd9160536405b51f9f029d869268503d2ec9bc
• Merged SHA: 2ecd9160536405b51f9f029d869268503d2ec9bc
• Required reviewers: (none required)
• CI status: no-runner-by-design (0 commit-status entries at HEAD)
• task_id: lr-0827ba
• Issue: Rate-limit auto-schedule state is global to the tab, not per-session — only one project can queue a resume message at a time #328