The HTML preferences pane was 430pt wide, which clipped the CSS theme
popup and its Reveal/Reload controls — most visible now that the bundled
"GitHub Dark Default" theme ships a long name. The pane is constraint-
driven and loadView pins each pane to its XIB design width, so widening
the content view to 482pt gives the theme controls room; the inner
controls reflow automatically. Adds a regression test guarding the width.

Reproduces the HTML-pane fix from yusufm's #419 on top of #461, preserving
#461's checkbox word-wrap.

Related to #419.

Co-authored-by: yusufm <[email protected]>

…#500)

## Summary

The Preferences window's toolbar tab highlight was getting stuck on the
first tab (General) when switching panes — pane content and window
resizing worked correctly, but the toolbar's selected-tab highlight
never visually moved off the first item. This was a regression from the
locale-aware dynamic pane-sizing rework in #481 and #498, which changed
`MPPreferencesViewController`'s `-loadView` to resolve each pane's
wrapper view across several Auto Layout passes before finally assigning
`self.view`. That extra work delays the moment a pane's view actually
lands in the window relative to when the vendored
`MASPreferencesWindowController` updates the toolbar's
`selectedItemIdentifier` during a tab switch, leaving the toolbar's
highlight stale even though the identifier itself is set correctly.

- Added a `-viewDidAppear` override to `MPPreferencesViewController`
that forces the toolbar to revalidate (`validateVisibleItems`) and the
window to redraw (`displayIfNeeded`) once a pane's view is actually
visible, without touching the two-pass sizing logic that fixed real
localization clipping bugs in #461/#481/#498.
- Added a doc-comment noting that subclasses overriding `-viewDidAppear`
must call `super`, or this fix is silently skipped for that pane
(verified none of the five pane subclasses currently override
`-viewDidAppear`; they only override `-viewWillAppear`).
- Added a regression test exercising the new override directly against
all five panes.

## Related Issue

Related to #499

## Manual Testing Plan

This session ran in a Linux sandbox with no Xcode/macOS, so the fix
could not be visually verified here — CI runs the automated suite, but
toolbar highlight rendering isn't observable through any public API a
headless test can assert on. Please verify manually on macOS:

1. **Setup:** Build and run MacDown 3000, open Preferences (⌘,). Toolbar
should show General, Markdown, Editor, Html, Terminal.
2. **Core scenarios** — for each, confirm both the correct pane loads
*and* the toolbar highlight moves to the clicked tab with no lag:
   - Forward order: General → Markdown → Editor → Html → Terminal
   - Backward order: Terminal → Html → Editor → Markdown → General
- Skipping around: General → Terminal → Markdown → Html → Editor →
General
- Re-click the same tab twice in a row — highlight should stay put, no
flicker
- Close and reopen Preferences — should reopen on the last-used pane
with correct highlight
3. **Edge cases:**
   - Rapid-fire clicking through all 5 tabs
- Clicking a tab while the window is still mid-resize from the previous
switch
- Keyboard tab switching if bound (MASPreferences'
goNextTab/goPreviousTab)
- Watch specifically for new jank from the added `displayIfNeeded` call
(double-flicker, brief flash of wrong highlight, redraw stutter)
   - Manually resize the Preferences window after switching tabs
4. **Locale:** The fix itself isn't locale-specific, but since #481/#498
were locale-driven, it's worth repeating scenario 2 once under Italian
(the originally reported repro locale) to confirm both the highlight bug
stays fixed and localized pane resizing still works correctly alongside
it.

## Review Notes

- Architectural review confirmed the vendored
`MASPreferencesWindowController` (CocoaPods, unmodified) already sets
`toolbar.selectedItemIdentifier` correctly on every pane switch, so the
fix targets our own `-loadView`/view-lifecycle timing rather than the
vendor pod.
- Code review confirmed `-viewDidAppear` is the correct lifecycle hook
(fires after the view lands in the window, unlike `-viewWillAppear`
which fires earlier in the same content-view-swap call), and that none
of the five pane subclasses currently shadow it.
- Documentation review of `plans/` found no existing content referencing
this behavior that needed updating.
- Note: the new regression test only proves the override doesn't crash
and runs for all five panes — it cannot prove the toolbar highlight
actually repaints, since that requires a real window server session.
Manual verification per the plan above is the actual confirmation this
bug is fixed.

…#500)

## Summary

The Preferences window's toolbar tab highlight was getting stuck on the
first tab (General) when switching panes — pane content and window
resizing worked correctly, but the toolbar's selected-tab highlight
never visually moved off the first item. This was a regression from the
locale-aware dynamic pane-sizing rework in #481 and #498, which changed
`MPPreferencesViewController`'s `-loadView` to resolve each pane's
wrapper view across several Auto Layout passes before finally assigning
`self.view`. That extra work delays the moment a pane's view actually
lands in the window relative to when the vendored
`MASPreferencesWindowController` updates the toolbar's
`selectedItemIdentifier` during a tab switch, leaving the toolbar's
highlight stale even though the identifier itself is set correctly.

- Added a `-viewDidAppear` override to `MPPreferencesViewController`
that forces the toolbar to revalidate (`validateVisibleItems`) and the
window to redraw (`displayIfNeeded`) once a pane's view is actually
visible, without touching the two-pass sizing logic that fixed real
localization clipping bugs in #461/#481/#498.
- Added a doc-comment noting that subclasses overriding `-viewDidAppear`
must call `super`, or this fix is silently skipped for that pane
(verified none of the five pane subclasses currently override
`-viewDidAppear`; they only override `-viewWillAppear`).
- Added a regression test exercising the new override directly against
all five panes.

## Related Issue

Related to #499

## Manual Testing Plan

This session ran in a Linux sandbox with no Xcode/macOS, so the fix
could not be visually verified here — CI runs the automated suite, but
toolbar highlight rendering isn't observable through any public API a
headless test can assert on. Please verify manually on macOS:

1. **Setup:** Build and run MacDown 3000, open Preferences (⌘,). Toolbar
should show General, Markdown, Editor, Html, Terminal.
2. **Core scenarios** — for each, confirm both the correct pane loads
*and* the toolbar highlight moves to the clicked tab with no lag:
   - Forward order: General → Markdown → Editor → Html → Terminal
   - Backward order: Terminal → Html → Editor → Markdown → General
- Skipping around: General → Terminal → Markdown → Html → Editor →
General
- Re-click the same tab twice in a row — highlight should stay put, no
flicker
- Close and reopen Preferences — should reopen on the last-used pane
with correct highlight
3. **Edge cases:**
   - Rapid-fire clicking through all 5 tabs
- Clicking a tab while the window is still mid-resize from the previous
switch
- Keyboard tab switching if bound (MASPreferences'
goNextTab/goPreviousTab)
- Watch specifically for new jank from the added `displayIfNeeded` call
(double-flicker, brief flash of wrong highlight, redraw stutter)
   - Manually resize the Preferences window after switching tabs
4. **Locale:** The fix itself isn't locale-specific, but since #481/#498
were locale-driven, it's worth repeating scenario 2 once under Italian
(the originally reported repro locale) to confirm both the highlight bug
stays fixed and localized pane resizing still works correctly alongside
it.

## Review Notes

- Architectural review confirmed the vendored
`MASPreferencesWindowController` (CocoaPods, unmodified) already sets
`toolbar.selectedItemIdentifier` correctly on every pane switch, so the
fix targets our own `-loadView`/view-lifecycle timing rather than the
vendor pod.
- Code review confirmed `-viewDidAppear` is the correct lifecycle hook
(fires after the view lands in the window, unlike `-viewWillAppear`
which fires earlier in the same content-view-swap call), and that none
of the five pane subclasses currently shadow it.
- Documentation review of `plans/` found no existing content referencing
this behavior that needed updating.
- Note: the new regression test only proves the override doesn't crash
and runs for all five panes — it cannot prove the toolbar highlight
actually repaints, since that requires a real window server session.
Manual verification per the plan above is the actual confirmation this
bug is fixed.