Accessibility: large-text options for the app chrome

[byronferguson]

Summary

Add an Accessibility section to the Settings window with 1–2 large-text options that scale the app chrome — the SwiftUI UI (sidebar worktree list, tab bar, toolbar labels, Settings panes) — independently of the terminal surface.

This is chrome-only. The Ghostty terminal surface already has its own font-size zoom, so this request explicitly does not touch terminal rendering.

Motivation

The app chrome is currently sized by the system default only. Users on high-resolution displays, or with low vision, have no in-app way to enlarge the sidebar/tab/toolbar text without changing the OS-wide display scale (which affects everything, including the terminal). AGENTS.md already mandates "Use Dynamic Type, avoid hardcoded font sizes", so the chrome is well-positioned to respond to a Dynamic Type override.

Proposed options (1–2, keep it minimal)

1. Chrome Text Size — a segmented / stepper control with a small set of discrete choices, e.g. Default, Large, Extra Large, mapped to DynamicTypeSize values (.large → .xLarge → .xxLarge) applied to the chrome view hierarchy.
2. (optional second) Bold Chrome Text — a toggle that applies .fontWeight(.semibold)/legibility weight to chrome labels for users who need higher contrast/weight rather than raw size.

Both persist as global settings and take effect live.

Implementation sketch

• Add an Accessibility case to the Settings section list and a matching AccessibilitySettingsView (mirror the existing AppearanceSettingsView pattern under SupacodeSettingsFeature/Views/).
• Add fields to GlobalSettings (SupacodeSettingsShared/Models/GlobalSettings.swift) — e.g. chromeTextSize: ChromeTextSize (new enum in SupacodeSettingsShared/Models) and optional boldChromeText: Bool — with decodeIfPresent defaults so existing settings files migrate cleanly.
• Surface the corresponding state in SettingsFeature.State and bind it in the new view.
• Apply the setting to the chrome root by injecting .dynamicTypeSize(...) (and, if adopted, a legibility/weight modifier) on the main window's chrome hierarchy — scoped so it does not propagate into the Ghostty surface view.

Acceptance criteria

• A new Accessibility section appears in Settings.
• Changing Chrome Text Size live-resizes sidebar, tab bar, toolbar, and Settings text — but leaves the terminal surface font unchanged.
• The choice persists across app restarts and older settings files decode without error.
• No hardcoded font sizes introduced; changes flow through Dynamic Type (per AGENTS.md).

Non-goals

• Changing the terminal surface font size (already handled by Ghostty zoom).
• A free-form numeric point-size field — keep it to a small set of discrete, system-mapped options.

[github-actions]

Thanks for your patience. This feature is approved and marked ready, so it is now open for a pull request. If you'd like to work on it, open a pull request and link it with Closes #662 in the description. If the issue is assigned to someone, it is reserved for them; otherwise anyone is welcome to pick it up.

See CONTRIBUTING.md for the full flow.

[sageframe-no-kaji]

I'd like to pick this up. Byron said on #595 that he probably won't have time for it, so if no one else is on it, could you assign it to me?

Two questions before I write anything.

Dynamic Type: I tried the .dynamicTypeSize(...) route from the sketch and could not get it to do anything. macOS SwiftUI doesn't resize text for Dynamic Type the way iOS does, so applying it at the window root had no visible effect on the sidebar, tab bar, or toolbars. What did work was a scale value in the environment plus a small appFont(_:) modifier that reads the live system point size for a semantic style (NSFont.preferredFont(forTextStyle:)) and multiplies it. Sizes still come from the system text styles and nothing is hardcoded, but it's opt-in per call site: each piece of chrome text has to use appFont(.body) instead of .font(.body). That means coverage is something I have to maintain rather than something that happens automatically. Is that an acceptable tradeoff, or would you rather I keep looking for a Dynamic Type route?

Shortcuts: alongside the Settings control, would you take View menu items for Increase / Decrease / Reset Text Size? I'd put them on ^⌘= / ^⌘- / ^⌘0, deliberately off ⌘+/⌘-/⌘0 so they never collide with the focused terminal surface's own zoom. Happy to leave them out if you want this to stay settings-only.

[sageframe-no-kaji]

PR #774 is up.

It takes the appFont(_:) route and leaves the View menu items out. Neither question got an answer, so flagging that I assumed rather than confirmed — say the word and I'll change either.

Dynamic Type / opt-in coverage. Went with the environment-scale approach; the mechanics are in the PR description. The tradeoff from my question above still stands: coverage is opt-in per call site, so chrome text that doesn't use appFont doesn't scale, and keeping that complete is maintenance rather than something that happens on its own. If you'd rather I keep looking for a Dynamic Type route, I'll go back to it.

Shortcuts. Left out — settings-only. Still glad to add View menu Increase / Decrease / Reset on ^⌘= / ^⌘- / ^⌘0, deliberately off ⌘+/⌘-/⌘0 so they can't collide with the focused terminal surface's own zoom. This PR or a follow-up, whichever you prefer.