feat(permissions): add auto permission mode to session pickers

[JeanBaptisteRenard]

Summary

• Claude Code recognizes auto as a --permission-mode value (verified live: claude -p ... --permission-mode auto exits 0) and treats it as its own default permission mode, but Switchboard's three permission pickers (New Session dialog, Resume Session dialog, Settings panel) never listed it.
• Added auto to all three, sourced from one shared PERMISSION_MODES list in public/utils.js instead of the two byte-identical arrays previously duplicated in public/dialogs.js (exactly how auto got missed after one copy was updated but not the other).
• Made auto the effective default for genuinely unconfigured installs (SETTING_DEFAULTS.permissionMode in main.js) without overloading the existing null sentinel: get-effective-settings now only falls through to SETTING_DEFAULTS on undefined (key never saved at that scope), so a user who explicitly saved "Default" (an intentional null, meaning prompt for every action, --permission-mode omitted) keeps that behavior instead of being silently upgraded to auto.
• dontAsk was left untouched — it's a legitimate CLI mode, not the defect here.

Test plan

• task test — full suite green (362/362), including new coverage in test/dom-permission-mode-picker.test.js:
  • auto is offered (and pre-selected when effective) in both New and Resume Session dialogs
  • auto survives the round-trip into the launched session's options, which main.js turns into --permission-mode "auto"
  • the two dialogs.js copies stay deduplicated behind PERMISSION_MODES (regression guard)
  • the Settings panel <select> offers auto and is built from the same shared list
  • static regression guard on main.js: SETTING_DEFAULTS.permissionMode === 'auto', and the get-effective-settings merge never reintroduces the !== null conflation that would silently rewrite an explicit "Default" into auto
• task lint — 0 errors (pre-existing warning-only baseline, unaffected)
• Manual CLI probe: claude -p "reply with the single word OK" --permission-mode auto → OK, exit 0

Note

Switchboard is normally run as a built AppImage — this code change won't be visible until the app is rebuilt (task build / npm run build:linux).

[JeanBaptisteRenard]

Superseded. Closing in favour of #89.

The PERMISSION_MODES hoist this PR carried was implemented independently upstream in doctly/switchboard@a7698f4 (2026-07-31) — the same diagnosis (the mode list copy-pasted three times, twice in dialogs.js plus hardcoded <option> tags in settings-panel.js), the same solution (hoist into PERMISSION_MODES in public/utils.js, drive all three call sites from it), and the same deliberate omission of manual. It arrived in this fork through the v0.0.31 sync, #88, so there is nothing left for us to contribute there.

What remains genuinely ours is the main.js half that upstream does not have:

• SETTING_DEFAULTS.permissionMode: 'auto'
• get-effective-settings honouring an explicitly-saved null instead of conflating it with an absent key

That is now #89, rebuilt on top of the synced tree, with the regression test kept (it also covers upstream's a7698f4, which shipped untested).

The null/undefined conflation is a real upstream bug independent of the default flip — an explicit null never won, so a project could not narrow permissionMode back to "Default", and any non-null SETTING_DEFAULTS value was unreachable at project scope. It is being reported and fixed upstream separately, without the default flip.