fix(session): let a roll-wide reset undo an unwanted setting (#1047)

[thetalkingdrum]

Summary

Fixes #1047: once a boolean setting (flip H/V, Normalize, Use Luma/Color Average) got
applied across a roll, there was no way to push the unchecked state back out. A misclick
meant fixing every frame by hand.

Root cause: GranularSettingsDialog (behind Apply/Paste/Sticky) pre-selects and
surfaces rows by comparing each field to WorkspaceConfig() defaults. A field a user set
and then reverted to its default is indistinguishable from "never touched," so it's hidden
and unticked by default — there's no live frame left to use as a "pristine" source once
every frame in the roll already holds the unwanted value.

Fix:

• Adds Reset Roll to Defaults… to the frame-list context menu (next to Apply Settings),
  which resets every visible frame to its own asset defaults in one step — reusing
  _asset_defaults, the same per-asset logic Reset Settings already uses, so a
  composite's inherited film process, a merge's seeded shadow lift, and stitch/triplet
  wiring survive the reset rather than being wiped by a blind WorkspaceConfig() overlay.
  Each frame's reset is still an ordinary undo step, and the active frame re-renders
  immediately.
• With several frames selected, Reset Settings itself becomes Reset N Frames and
  resets the whole selection instead of only the active frame — the same confirm-gated
  reset_roll_settings, just scoped to state.selected_indices instead of the whole
  visible roll. Single-frame Reset Settings is unchanged (still unconfirmed, one click).
• Closes a separate catalog gap: Normalize (e6_normalize), Use Luma Average, and
  Use Color Average had no SettingRow at all, so they were invisible to Apply/Paste/
  Sticky in either direction, independent of the reset gap above. e6_normalize is also
  a metering input — it decides whether an E-6 frame's highlight point comes from sampling
  the image or a fixed offset from the shadow — so it's registered in
  _BOUNDS_INPUT_FIELDS alongside its two siblings, or applying it alone would leave a
  target frame's cached bounds stale.

What this doesn't fix

The default-diff heuristic behind GranularSettingsDialog/_row_edited is unchanged: Apply
Settings still can't tell "this field is at its default because the user put it there" apart
from "never touched," so a source frame holding an unwanted-but-default value still won't
pre-select or propagate through the normal Apply Settings picker. This PR is a blunt escape
hatch for that case, not a fix to the picker itself. The root fix would track which fields a
user has actually interacted with, independent of the resulting value — no such tracking
exists anywhere in WorkspaceConfig/session today — which is a bigger redesign than this
issue's reported symptom calls for. Flagging it in case it's worth its own issue.

Known limitation (pre-existing, not introduced here)

A reset frame that isn't the active one keeps a stale film-strip thumbnail until you
select it — selecting it renders it correctly right away, so the underlying setting is
correct, only the thumbnail lags. This is not new: Apply Settings and Apply Preset
have the same gap today, since thumbnails only regenerate as a side effect of actually
rendering a frame, and both write straight to the DB for every frame but the active one.
Worth its own follow-up covering all three actions rather than a partial fix here.

Heads up on overlapping open PRs

• Housekeeping: sticky settings master toggle, Normalize catalog row #1114 adds the same Normalize catalog row (same field, same sticky=True, one line
  apart). Real but trivial overlap — whichever of us merges second will hit a one-line
  conflict on that row and should just drop the now-redundant addition.
• feat(ui): reset a whole tab from its icon's context menu #1117 adds a differently-scoped "Reset Setup to Defaults" (per tab, current frame
  only) via a tab icon's context menu. No code overlap with this PR, but the two "Reset X
  to Defaults" names landing around the same time might be worth reconciling for clarity.
• feat(thumbnails): background thumbnail refresh + manual Update Thumbnails control #1127 (now ready for review too) is a real, literal conflict, not just a naming one:
  it inserts a frames_edited_offscreen.emit(...) block at the tail of
  apply_preset_fields, the exact point reset_roll_settings is inserted right after in
  this PR — same hunk in session.py. It also edits the identical docs/USER_GUIDE.md
  right-click-menu sentence this PR does. Both are trivial to resolve by keeping both
  additions; whichever of us merges second does it by hand. Separately: feat(thumbnails): background thumbnail refresh + manual Update Thumbnails control #1127's background
  thumbnail refresh wires frames_edited_offscreen into Apply Settings/Apply Preset/Batch
  Analysis/etc., but not into this PR's reset_roll_settings — so the "Known limitation"
  thumbnail-staleness note above stays open for the roll/selection reset paths even after
  feat(thumbnails): background thumbnail refresh + manual Update Thumbnails control #1127 lands, unless reset_roll_settings is later wired to emit it too (or Film strip: two-column negative stats, stale-thumbnail indicator #1115's
  stale-dot approach lands and catches it structurally instead).

Testing

make all (lint + type + full pytest) passes, with the one known pre-existing failure
(test_load_tooltip_follows_a_rebinding, a macOS key-symbol rendering difference — fails
the same way on main with this branch stashed, and CI runs Ubuntu).

Also verified end-to-end against the real FileBrowser widget and a real SQLite-backed
StorageRepository, and manually in the running app: the menu item appears correctly
positioned, the confirm dialog reports the right frame count, the active frame's canvas
updates immediately, and every frame's setting reverts to default with no crash. The
multi-frame-selection path got the same treatment, plus a driver run against real scans
from a live roll confirming a selected-but-inactive frame resets and an unselected frame is
left untouched.