feat(session-title): support throttling all-prompts title revisions (e.g. every N prompts / idle debounce)

[TecFancy]

Motivation

dsh-session-title-all-prompts-llm (cadence all-prompts) starts a new title revision after every eligible human prompt: in SessionTitleService.onUserMessage, registration.provider.automatic === 'all-prompts' always schedules a revision. Each revision makes an auxiliary LLM call over the full (growing) message prefix.

For long-lived sessions this has two practical costs:

1. Token spend — one auxiliary title call per user message, over a history that grows every turn.
2. Title churn / noise — back-and-forth threads retitle on nearly every prompt; sidebar session-list titles keep changing unprompted, which makes the title less useful as a stable navigation label. It also works against "recap-style" UX: a title should settle on the conversation's topic, not flutter per message.

first-prompt avoids this but titles only once and never follows topic drift — so deployments are forced to choose between "never updates" and "updates every message", with no middle ground.

Behavior

Let deployments bound how often automatic revisions run, via one or both optional settings:

1. Min-gap cadence — minPromptsBetweenRevisions: N (default 1 = current behavior): skip automatic generation until at least N additional eligible user prompts arrived since the last started revision.
2. Inactivity debounce (recap-style) — debounceMs: M (default 0 = current): start the revision only after the user has been idle for M ms, so a dense exchange settles on one title.

Invariants: an explicit ctx.sessionTitle.refresh() always bypasses the throttle (it is already the deliberate manual unpin); a user rename() still pins and is never auto-overridden; first-prompt is unaffected. Defaults reproduce today exactly (backward compatible).

Example:

- id: session-title-all-prompts
  name: '@deepseek-ai/dsh-session-title-all-prompts-llm'
  config:
    minPromptsBetweenRevisions: 5   # retitle on every 5th prompt
    debounceMs: 15000               # and only after 15s idle

Suggested implementation point (helpful, not required): add the fields to the shared SessionTitleLlmConfig in @deepseek-ai/dsh-session-title-llm (both shipped providers already delegate to it), and gate shouldSchedule in the all-prompts branch of SessionTitleService.onUserMessage on the count / idle thresholds.

Why the service layer, not a wrapper plugin

• The scheduling decision lives in SessionTitleService, and SessionTitleAutomaticMode is a small closed union ('first-prompt' | 'all-prompts'). A config option on the shared title policy is the smallest coherent surface; a per-deploy fork would collide with register()'s single-provider contract and fragment the ecosystem.
• first-prompt keeps its current behavior; only deployments that opt in via config change anything.

Checklist (if accepted)

• Add minPromptsBetweenRevisions / debounceMs to SessionTitleLlmConfig, defaults preserving current behavior
• Wire into SessionTitleService.onUserMessage scheduling (count + idle thresholds)
• refresh() and user renames bypass the throttle
• Update dsh-session-title-all-prompts-llm README + config catalog
• Tests: N-gap cadence, debounce reset on new prompt, supersession with throttle, refresh() bypass

[TecFancy]

Just to add real-world weight behind this: I enabled the official all-prompts provider in production today (0.1.2-rc.1), and on an active long-lived session the title already re-ran on nearly every prompt — each time over the full growing history. Two observations from actual use:

1. Cost is visible: each revision is a separate auxiliary call; on token-metered setups this adds up fast on chatty sessions.
2. Title churn hurts discoverability: with several sessions open side by side, the list rows keep changing every few minutes — ironically making it harder to spot the session I want.

What would make this land well for me:

• minPromptsBetweenRevisions (every N prompts) as the primary control — simple, predictable, cheap.
• debounceMs as a nice complement so a dense exchange settles on one title.
• Both defaulting to current behavior (1 / 0) so existing deployments are untouched.
• refresh() / user rename must keep bypassing the throttle.

Happy to test a patch or help refine the design if maintainers want a concrete proposal. Thanks for considering!