feat: make the resume session cap configurable, and raise it to 200

[saucam]

What

On daemon start, codeoid restores sessions from disk newest-first under two guards: a count cap and a 20-second deadline. The cap was a hardcoded 50.

This makes the cap configurable and raises the default to 200.

Why

On a daemon that keeps many long-lived sessions, the count cap binds long before the deadline does. A daemon with 93 sessions on disk restored 50 and left 43 behind:

[codeoid] resume: restored 50 of 93 session(s); 43 left over the 50-session cap,
0 skipped past the 20000ms deadline (still on disk; loadable on a future restart).

Nothing was lost — those sessions stay on disk — but the only way to get them back was to edit the constant and restart. That is the kind of local edit that lives on as an uncommitted diff across machines and gets reverted by the next git pull.

Of the two guards, the deadline is the one that actually protects startup: it measures real work done, where the count is a guess about how much work 50 sessions represent. Letting the deadline bind first is the better default, so the cap becomes a backstop rather than the primary limit.

How

Surface
config.json	session.resumeMaxSessions — zod-validated, min(1), default 200
Env	CODEOID_RESUME_MAX_SESSIONS (table-driven override, kind: "int")
Web UI	added to the settings manifest under Session defaults (advanced)
Docs	docs/CONFIGURATION.md

session-manager reads this.#config?.session?.resumeMaxSessions ?? RESUME_MAX_SESSIONS_DEFAULT, matching the existing collaboration.maxLiveChildren idiom, so no process.env read leaks outside config.ts and tests can still construct a manager without config.

The startup log now reports the cap actually in use rather than a literal 50.

Behaviour change

Daemons that never set this go from restoring up to 50 sessions to up to 200. Startup cost stays bounded by the unchanged 20s deadline, so the practical effect on a machine with few sessions is nil, and on a busy one it trades a few seconds of startup for sessions that are actually there. Sessions past the cap behave as before: left on disk, loaded on a later restart.

Verification

• bun run typecheck clean
• bun run lint clean (372 files)
• bun test — 2593 pass, 12 skip, 0 fail
• Run on two daemons: one restored 97 sessions, the other 93 of 93 (both previously capped at 50)

🤖 Generated with Claude Code