T1.5 - F5 (interim): wizard fields stop looking disabled

INTERIM. T3.4 removes the duplicate token underneath this; the job here is only
the appearance, and no token consolidation is started.

The wizard filled its inputs with var(--bg) - which in this sheet is the PAGE
BACKGROUND, #f4f4f4 - on a #e0e0e0 border. An empty required field was
indistinguishable from a locked one, which is why people were not typing in
them. The cause is the one the review named: this sheet redeclares its own
tokens, so it never saw --cds-field: #ffffff, even though theme-light.css has
been supplying that to this page all along.

Fields now consume --cds-field, and take the same --border-strong the creator's
inputs already use, so a field looks like a field on both pages. No new value is
introduced - both tokens already existed.

That inverts a signal if left there, so it needed the other half: there was no
disabled rule at all on this page, meaning locked fields would have turned white
too. Disabled and readonly fields now take --cds-field-02, the theme's own
secondary field surface, matching .locked-field in the creator. Enabled #ffffff
against disabled #f4f4f4, verified by computed style rather than by eye.

The border is deliberately the same on both states. I first wrote
`border-color: var(--border)` on the disabled rule and could not demonstrate it
taking effect - the rule matches, is more specific than the base rule, and its
background applies, but the computed border stayed --border-strong. Rather than
ship a declaration whose effect I cannot show, it is gone: a consistent border
is what "consistent with inputs elsewhere" asks for, and the fill is what
carries the state.

Screenshot diff is limited to the wizard, but establishing that took a control
run. admin and users appeared to change too, until capturing twice with NO code
change showed they differ from themselves - the console pages render live
timestamps and are not byte-stable. login, launcher, sop, creator and field are.
Recorded in the baseline README so the next task with a "no layout change"
done-when does not chase it.

The F5 probe now also fails if enabled and disabled fields become identical,
which is the way this fix could silently go wrong.

f_items: F1-F5 FIXED, F6 untouched as wave 1 requires. browser_check 71/71.

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

docs/reference/baseline/README.md

@@ -31,6 +31,17 @@ python tests/baseline_shots.py --out /tmp/after --label after
 declares `width=device-width`, so this is the layout a field tablet actually gets. The script
 asserts the width it asked for is the width the page saw.
 
+### Two pages are not byte-stable — do not diff them blindly
+
+Found at `T1.5`. Capturing twice with **no code change at all** produces different bytes for
+`admin` and `users` at both widths. `login`, `launcher`, `sop`, `creator` and `field` are
+stable. The console pages render live timestamps, so a byte comparison of them reports a
+change on every run.
+
+A task whose done-when is "no layout change at 1440px" therefore cannot use a byte diff on
+those two. Run the capture twice before drawing any conclusion, or compare a page that is
+stable. Four of the "changes" in this document's own history were this, not code.
+
 ## F1–F6: all six reproduce
 
 Measured in a browser by `tests/f_items.py`, not read from source. Re-run any time: