feat(core): rotate sessions after idle inactivity

[xukp20]

Summary

Add project-level reset_on_idle_mins to automatically rotate to a fresh session after prolonged user inactivity.

This addresses #390, but uses a safer behavior than literally auto-running the current /new implementation.

Fixes #390

What changed

• add project-level reset_on_idle_mins
• only apply idle reset to normal user messages
• rotate to a fresh active session when the previous session has been idle past the configured threshold
• preserve the old session history instead of destructively clearing it
• show a user-facing auto-reset notice before processing the new message
• add config validation and regression coverage
• document the new option in README, usage docs, and config.example.toml

Why this design

The original issue suggests “execute /new automatically after inactivity”.

Current /new in main does more than just create a new active session: it also clears the old
session’s backend binding and history.

That would be too destructive for automatic idle rotation.

This PR therefore uses a safer behavior:

• keep the old session intact for later /list / /switch
• create a new active session for the next normal message
• continue processing the current message in that fresh session

So this behaves more like:

• automatic session rotation after inactivity

rather than:

• destructive reset of the old session

Validation

• pnpm install --frozen-lockfile && pnpm build in web/
• go build ./...
• go test ./... -v -race
• go test ./... -coverprofile=coverage.out -covermode=atomic
• actionlint -color
• go test -v -tags=smoke,no_web ./tests/e2e/...
• go test -v -tags=regression,no_web ./tests/e2e/...
• go test -bench=. -benchmem -tags=performance,no_web ./tests/performance/...
• real Feishu manual verification with reset_on_idle_mins = 1

[xukp20]

Follow-up on two ideas mentioned in the issue:

1. Per-platform setting

I intentionally implemented this as a project-level option instead of a per-platform option.

My reasoning is that this behavior is really about cc-connect session lifecycle, not about a specific platform capability.

If a project is connected to multiple platforms, a per-platform idle reset policy would make session semantics much harder to reason about:

• which platform’s idle timer should win
• whether different platforms should rotate the same active session differently
• how to explain that behavior to users

So for this first version, project-level scope felt much cleaner and more consistent.

2. Notify / ask for confirmation before resetting

I think this is a reasonable follow-up idea, but I did not include it in this PR because it adds a lot of extra interaction complexity:

• how confirmation should work on platforms without buttons/cards
• what happens if the user does not reply
• how long the confirmation should remain pending
• how it should interact with the next incoming normal message
• how to handle pending/busy session state safely

For this PR, I intentionally kept the behavior minimal and deterministic:

• if the session has been idle longer than the configured threshold
• the next normal message starts in a fresh session automatically
• the user still gets a visible notice that the rotation happened

If maintainers think confirmation is important, I would suggest treating that as a follow-up enhancement, for example with a separate mode such as:

• auto
• confirm

[chenhg5]

LGTM. Smart design for idle session rotation.

Review summary:

• ✅ Safer than auto-/new (preserves old session for /list / /switch)
• ✅ User-facing notice before processing
• ✅ Config validation
• ✅ Documentation updated
• ✅ CI passes
• ✅ Fixes #390

Good feature for maintaining fresh agent contexts.