T5.6 - CR-002: Acumatica cost code and task, hidden by toggle

The team concluded these two are noise on a field work package: cost codes are
effectively constant on a job and the Acumatica task mapping is a PM concern.
The cost visibility they actually want is by building and floor, which is CR-004
and CR-018.

Hidden, not removed. CLAUDE.md: "Removed fields are hidden, not deleted (CR-002,
CR-016). Retain the data and the model." So this is a second, narrower toggle
list beside T5.5's sections - two fields inside General Information rather than
two more sections, because a section is a block of the document and these are
two rows in one.

  no migration           the values live in the work package's JSON data blob,
                         which nothing here writes to. The probe greps every
                         migration for a drop_column touching either.
  no model change        server/models.py is untouched by this task
  no code change to      the toggles are SOP data. Another project turns them
  re-enable              back on from step 12 and both fields return, values
                         included

A field is on only if its own toggle is on AND the section holding it is. Asked
as one question (WPSections.fieldOn) so no caller has to remember to ask both -
a field showing inside a hidden section is not a state worth reasoning about,
and the probe checks that case explicitly.

  html/wp-sections.js            FIELDS, fieldOn, normalizeFields
  html/work-package-suite-app.js field rows nested under their section
  html/work-package-suite-styles.css .field-toggle
  html/wp-creation-index.html    ids on the two .field wrappers
  html/wp-creation-app.js        WP_FIELD_NODES; both document rows conditional
  tests/sections_check.py        +22 checks (53 -> 75)

Done when
  [x] neither field appears in the form, detail view or PDF export when off
  [x] existing records still hold their values - a package EDITED while both are
      off comes back through collectPackage() with both intact
  [x] the fields can be re-enabled for another SOP without a code change
  [x] no schema migration drops data - checked against every migration in the
      tree, not just the ones this wave added

The whole .field wrapper is hidden, not the input: a bare label over nothing is
worse than either state.

Raised, not fixed
  BL-019  A cost code that has left COST_CODES is silently blanked on edit.
          wp_cost is a <select>, and setting .value to something with no matching
          <option> does nothing at all - so opening such a package clears the
          field and the next save writes the blank back. The same bug was fixed
          once already for gov_wosize (work-package-suite-app.js:490-495) by
          adding the stored value as an option; cost code never got it.

          Found the honest way: a probe here used an invented cost code to prove
          hiding a field does not delete its value, and the value came back
          empty. That looked exactly like the toggle eating data. It was not, and
          the probe now uses a real code and says why in a comment - a probe that
          fails for a reason other than the one it names is worse than no probe.

Verified one at a time
  sections_check  75/75  (53 + 22 for CR-002)
  browser_check   71/71
  stepper_check   70/70
  a11y            22/22
  url_state       23/23
  autosave        34/34
  locations_check 58/58

Question for the PR, per CLAUDE.md: BL-000b asks whether General Information
wants per-field toggles generally. This is not that - it is the two fields
CR-002 names, and the list is deliberately closed. If a third field wants one,
that is the general question and it needs the product answer BL-000b is holding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/waves/backlog.md

@@ -324,6 +324,28 @@ deliberately deferred.
   rebuild unchanged. Either way `browser_check.py`'s fixture should adopt the `{sop, state}`
   shape so it stops being the only place this discrepancy is visible.
 
+### BL-019 — A cost code that has left the list is silently blanked on edit
+
+- **Found during:** T5.6
+- **Where:** `html/wp-creation-app.js` — `buildCostCodes()` at `:185`, consumed by
+  `loadPackageIntoForm()`
+- **What:** `wp_cost` is a `<select>` built from the hardcoded `COST_CODES` array, and
+  `loadPackageIntoForm` sets `.value` from the saved package. Setting `.value` to something
+  with no matching `<option>` does nothing at all — silently — so opening a package whose
+  cost code has since been removed from the array, or that was imported from elsewhere,
+  clears the field. The next save writes the blank back over the record.
+- **The same class of bug was already fixed once**, for `gov_wosize` in
+  `work-package-suite-app.js:490-495`, by adding the stored value as an option when it is not
+  a preset. The comment there names the reason: "if a saved value isn't one of the presets,
+  add it as an option so the round-trip preserves it." Cost code never got the same treatment.
+- **Found because** a `T5.6` probe used an invented cost code to prove that hiding a field
+  does not delete its value, and the value came back empty — which looked like the toggle
+  eating data and was not. The probe now uses a real code and says why.
+- **Why not now:** `T5.6` hides two fields; it does not own how one of them round-trips, and
+  a fix here changes what is written back to existing records — which wants its own diff.
+- **Suggested wave or follow-up:** wave 9. The fix is the four lines already written for
+  `gov_wosize`.
+
 ### BL-014 — Four controls fall back to the browser's default focus ring
 
 - **Found during:** T3.4