Document the ContentTier DISCARD_EDITS preserve-vs-discard rule in wizardReducer.ts

[steilerDev]

As a developer adding a new field to the report wizard's ContentTier, I want the DISCARD_EDITS preserve-vs-discard rule stated where I am already looking, so that I do not have to reverse-engineer it from one field's exception comment or find it in the wiki I did not know to open.

Parent Epic: none — part of the parent-less Bank Report Wizard cluster (#1876–#1879, #1898–#1901, #1923, #1965, #1973).
Priority: Could Have
Source: product-architect follow-up suggestion on PR #2010, confirmed non-blocking. Filed 2026-08-05.

Problem

DISCARD_EDITS in client/src/pages/ReportWizardPage/wizardReducer.ts spreads freshContentTier() and then explicitly re-preserves hiddenColumns. #2010 documented why that one field is an exception in a comment at the exception site — good, and it does keep a future refactor from "fixing" the asymmetry away.

What is not written down anywhere in the reducer is the general rule that makes it an exception: every ContentTier field is discarded by DISCARD_EDITS by default, and opting out requires an explicit re-preservation line plus a stated reason. The next person adding a ContentTier field will add it to the interface and to freshContentTier(), and will silently inherit "discarded on DISCARD_EDITS" without ever deciding whether that is right for their field.

The architect documented the rule in the wiki's new "Multi-step wizard state: tier factories" section but deliberately did not touch the reducer, since only one production-file comment edit was authorised on that PR. The wiki is the right home for the architecture; the reducer is the right home for the reminder.

Acceptance Criteria

• 1 A comment at the ContentTier interface (or at freshContentTier() — whichever a new field is added to first) states the default: fields on this tier are cleared by DISCARD_EDITS and reset by SELECT_USE_CASE, and any field that should survive one of those must re-preserve itself explicitly with a stated reason.
• 2 The comment names hiddenColumns as the existing exception and points to the DISCARD_EDITS case, so the rule and its one instance are reachable from each other in both directions.
• 3 The comment points to the wiki's "Multi-step wizard state: tier factories" section for the full rationale rather than restating it — the reducer carries the reminder, the wiki carries the architecture.
• 4 No behaviour change. No test changes beyond what a comment edit requires (i.e. none). The existing DISCARD_EDITS and SELECT_USE_CASE reducer tests still pass unmodified.

Notes

• Comment-only, single file, frontend-developer. S-sized — suitable for bundling with other small items rather than its own development cycle.
• This is the "comment keeps the rationale, issue owns the guard" pattern inverted: here the guard already exists (the hiddenColumns re-preservation line plus its tests), and what is missing is the rule that tells the next person the guard was a decision rather than an accident.

Dependencies

• Blocked by Report column visibility: wire the preview toggles through to the generated PDF #1973 (documents state that issue introduces).