[Feature]: Use NumberField for the auto-settle inactivity days input

[HugoVizcainoSantana]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case.

Area

apps/web Settings (desktop wraps the same UI)

Problem or use case

Settings has two day-count inputs that look and behave differently:

1. Storage cleanup (RetentionControl, apps/web/src/components/settings/StorageSettings.tsx) uses the shared NumberField: − / value / inline days / +, size="sm", commits on onValueCommitted.
2. Auto-settle inactivity (AutoSettleDaysInput, apps/web/src/components/settings/SettingsPanels.tsx) is still a plain <Input type="number">: native browser spinner, no unit label, commits on every keystroke and snaps back on blur.

Same kind of value, two controls. SettingsPanels already uses NumberField for the Git fetch interval, so the older days input is the odd one out.

Proposed solution

Render AutoSettleDaysInput with the same NumberField composition Storage cleanup uses (steppers, inline days, size="sm", commit on onValueCommitted). Keep the 1–90 range (MIN/MAX_SIDEBAR_AUTO_SETTLE_AFTER_DAYS) and leave the enable switch on its current row. Do not fold this into RetentionControl; it owns its own switch, range, and default.

Out of scope: mobile (already has native days fields), port and price inputs, browser toolbar viewport fields. No contract or server change.

[juliusmarminge]

Triage

Confirmed on current main. Settings really does have two day-count controls with different widgets and commit behavior. This is a valid, small web/desktop UI consistency enhancement — not a functional bug, and not a duplicate of #7251.

What we checked

AutoSettleDaysInput in apps/web/src/components/settings/SettingsPanels.tsx is still a plain <Input type="number">: native spinner, no unit label, local draft, commit on every keystroke, snap-back on blur. Range is already MIN/MAX_SIDEBAR_AUTO_SETTLE_AFTER_DAYS (1–90).

Storage cleanup’s RetentionControl in apps/web/src/components/settings/StorageSettings.tsx uses the shared NumberField: − / value / inline days / +, size="sm", commit on onValueCommitted. That pattern landed in #11598.

SettingsPanels already imports NumberField* and uses them for Git fetch / health / power intervals, so this days field is the odd one out. The enable switch stays on the parent “Auto-settle inactive threads” row; the days row only renders when the setting is non-null. Do not fold this into RetentionControl (different switch, 1–3650 range, default 8).

Out of scope, as filed: mobile AutoSettleDaysField.* (already native days fields), port inputs, browser toolbar viewport fields. No contract or server change.

Related, not the same

#7251 (still open) is visual hierarchy — the days row looking like a top-level setting. Closed-unmerged #7093 only added indent/bg-muted/20. That is independent of this NumberField swap; do not close either as a duplicate of the other.

#9281 already unified settings control sizing; this issue is widget + commit timing.

Suggested fix

Replace only AutoSettleDaysInput with the same NumberField composition RetentionControl uses (steppers, inline days, size="sm", onValueCommitted), keep 1–90, leave the switch on its current row.

Type: enhancement (low / cosmetic). Next: implement as specified; small localized change.

[HugoVizcainoSantana]

Working on this now, following the triage: only AutoSettleDaysInput moves to NumberField, the 1–90 range stays, and the switch stays on its row.

One thing I noticed while doing it: the new code ends up almost identical to the NumberField block inside RetentionControl (same draft/saved-value handling, same clamp and round on onValueCommitted, same width trick with Intl.NumberFormat, same inline days label, same classes). Only min/max and the aria-labels are different.

I'm keeping it duplicated here so this change stays small, as requested. But would you be open to a follow-up that moves that inner block into a small shared component (something like DaysNumberField with value, min, max, label, onCommit) and uses it from both places? Each parent would still own its switch, range and default, so nothing gets merged into RetentionControl. Happy to open it as a separate issue/PR right after this one lands if you think it's useful.