fix: schedule 11 styling

[SScholefield]

Description

Eight UI fixes to the Schedule 11 (Basic Silviculture Costs) screen from a styling review against
the legacy app. No API, DTO, or backend changes — the entire diff is three files under
frontend/src/components/schedule11/, so it touches nothing owned by the other in-flight schedule
branches.

Each change was checked against the legacy JSF source rather than eyeballed, and most turned out to
be restoring behaviour the legacy screen already had:

#	Change	Grounding
1	Add New Location panel moved above the locations table	Legacy renders addLocationPnl before locationsDT (schedule11.xhtml:57, :204)
2	Columns reordered + relabelled to Location | Biogeo/Subzone/Variant | ES | NAR(ha) | Actual Cost ($) | Planned Cost ($) | Total Act Plus Plan Cost ($) | Total/NAR(ha) | Comments | Actions	Header text and order verbatim from xhtml:208-364
3	Totals row now bold on the header's grey	Matches the existing .schedule-1-other-costs__totals / .schedule-3-sub__totals rule; same --cds-layer-accent-01 token the data-table header uses
4	Per-page Mill / Reporting Year / Status block removed	Legacy's equivalent panel is commented out (xhtml:40-54); the app-wide ContextBanner already carries the working context on every page
5	Add-panel field labels at 14px	Matches the sibling precedent .schedule-3__section .cds--label
6	Comments moved to its own wider row below the field row	Legacy gave it rows="3" cols="75" (xhtml:140-141) — far wider than the neighbouring inputs; ported as a 75ch cap so it scales with the font
7	All columns sortable except Comments and Actions	Every legacy p:column carries sortBy except Comments (xhtml:353) and Delete (xhtml:364)
8	Stray per-cell labels removed from inline edit	The row's text inputs already passed hideLabel; the Dropdown and ComboBox did not, so "Edit Enhanced" / "Edit Biogeo/Subzone/Variant" printed as visible text above every editing row

Fixes #239

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality) — column sorting ([DOCS]: Site Map #7)

How Has This Been Tested?

• New component tests
• Updated existing tests
• Manual tests — not yet done, see Further comments

Schedule11.test.tsx grows 29 → 37 tests. Full suite: 354/354 passing (20/20 files), plus
eslint, stylelint, tsc --noEmit and vite build all clean on the merged branch.

New coverage for sorting:

• the exact sortable/non-sortable column set, asserted per column
• the ASC → DESC → NONE cycle with aria-sort assertions at each step
• numeric columns sort by value, not lexicographically (fixture uses 9 / 60 / 120.5 — a string sort
  would order 120.5 first)
• blank cells rank last in both directions, never above real values
• booleans sort false-before-true
• switching sort column resets the previous column to unsorted
• sorting still applies after a mutation refreshes the document

Plus one accessibility regression guard for #8: it asserts the Dropdown's label is present but
cds--visually-hidden, the ComboBox renders no visible label, and both controls are still
reachable via getByRole('combobox', { name: … }). That last pair is what fails if anyone later
"simplifies" this to display: none.

Checklist

• I have read the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation — n/a, no doc-visible behaviour change
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have already been accepted and merged

Further comments

Not yet verified in a browser. Everything above is covered by unit tests, typecheck, lint and a
production build, but six of the eight changes are purely visual and none has been viewed rendered.
Worth a reviewer pulling the branch and looking at the page. The highest-risk spots are the numeric
header alignment (#7, see below) and the gap between the table title and the table (#2/#3).

Three deliberate deviations from legacy, called out so they're a conscious review decision:

1. Sort cycles ASC → DESC → NONE. Legacy PrimeFaces only toggled asc/desc. Without the third
   state there is no way back to the document order the API returned, and the three-state cycle is
   what Carbon's own DataTable does. One-line revert in NEXT_DIRECTION if the team prefers strict
   parity.
2. Nulls rank last in both sort directions. A null has no natural position, and letting the
   direction flip it would push empty rows above real data on the descending pass. I could not
   confirm legacy's nullSortOrder default with confidence, so this is a chosen behaviour rather
   than a ported one.
3. Labels at 14px, where legacy's base is font-size: 12px Verdana (main.css:174-175). Verdana
   at 12px sits visually close to IBM Plex at 14px because of its larger x-height, so 14px is the
   better perceptual match than Carbon's nominal 12px — but it is not a literal legacy value.

Two implementation notes reviewers may query:

• The table title is now an h3, not TableContainer's title prop. Carbon routes that prop
  through its Section/Heading pair, which both sizes it at heading-03 (20px) and picks its own
  level (h2) — so the page's two section headings disagreed on size and skipped a heading level. It
  now uses the same element and class as "Add New Location", making them the same size by
  construction rather than by CSS override. The table keeps its accessible name via aria-label.
• ComboBox has no hideLabel prop (unlike Dropdown), so hiding its label in table rows is
  done by dropping titleText and passing aria-label — Carbon falls back to aria-label on the
  input exactly when titleText is absent. This keeps the accessible name that a display: none
  would have destroyed.
• One CSS rule exists purely because of sorting: a sortable header's label lives inside Carbon's flex
  button, so text-align: right on the th stops working and the numeric headers would drift left
  of their right-aligned cells. Hence .schedule-11__num .cds--table-sort { justify-content: flex-end }.

Follow-up, deliberately out of scope: Schedules 1, 2, 3, 4 and 8 all pair a TableContainer title with an h3 and so have the same heading size/level mismatch as #2 above, and the totals-row
hover quirk (Carbon's row hover out-specifies a single-class totals background) exists on the two
sibling pages too. Both are left alone here to avoid conflicting with the other active schedule
branches — candidates for the consistency PR.

---

Thanks for the PR!

Deployments, as required, will be available below:

• Frontend
• Backend

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are deployed in:

• Merge Workflow

[paulushcgcj]

The Schedule 11 presentation changes are well covered by the focused unit suite, and the consolidated column definition is a particularly readable choice. Before we merge, can we complete and record the manual Dev/Prod verification called out by the linked issue? The remaining visual behavior is not exercised by the tests. I also found one test whose name does not match the interaction it performs, which makes the sorting coverage harder to interpret.

Additional notes (not tied to a specific diff line):

• [frontend/src/components/schedule11/index.tsx] Before we merge, can we complete and record the manual Dev/Prod verification required by the linked issue? Its Definition of Done explicitly includes manual testing of all PRs in Dev and Prod, while this PR marks that work as not done and says the six visual changes have not been viewed rendered. The focused unit suite gives us good coverage, but it cannot validate the Carbon layout, responsive wrapping, heading spacing, totals-row hover, or numeric header alignment in a browser.

[gpascucci]

Approved! This is an exceptionally high-quality, comprehensive, and well-tested frontend polish pass for Schedule 11, @SScholefield.

• Complete Alignment & Polish: The column reordering, bold totals row on grey headers, and moving comments to its own wider row under fields perfectly restore the legacy JSF behavior beautifully.
• Robust Column Sorting: The ASC -> DESC -> NONE sorting cycle is highly robust, and the new comprehensive unit tests in Schedule11.test.tsx (all 354 tests green!) provide superb protection for sorting nulls, lexicographical values, and sort survival after mutations.
• Resolution of Comments: Both of Paulo's comments have been beautifully resolved (the sorting-survival test flow has been fixed and aligned with the test name, and the manual Dev verification was completed and recorded with screenshots).

An absolutely stellar, production-ready frontend pass!

[paulushcgcj]

Focused Schedule 11 tests, lint, build, and diff checks are green.
The consolidated column definition keeps the table behavior and presentation aligned.
I did not identify any additional high- or medium-confidence changes beyond the existing threads.