cards: one neutral surface, and the generated fill deleted with it

A card's fill stops being a function of the note. One neutral per theme on
all three surfaces — white in light, neutral-900 in dark, which is what the
palette's `default` always was and what both editors already used, so this
is a collapse onto a surface everything already had rather than a colour
anybody has to like.

Measured, against "not the same color as their background but close to it":
card vs board 1.04 light / 1.10 dark, edge vs card 1.98 / 1.73, body text
17.93 / 17.17, muted 10.37 / 14.23. The fill is deliberately the weakest
number on the card — the edge and the shadow separate it from the board, so
a fill that separated on its own would make it a panel.

Deleted, since the card was their only consumer: `derivedFill` / `hslHex`
and the level tables in colors.ts, `derivedFillArgb` / `hslToArgb` in
DerivedTint.kt, `NOTE_CARD_CLASSES_STRONG`, `chosenNoteColor`,
`noteCardClasses`, `noteTintVars`, the `.note-tint` rule in style.css,
`chosenBackground` / `tintable` / `noteTintFor` / `noteCardColor` /
`noteIsStrong` / `firstLabelColor` in NoteTint.kt, and
`resolvedNoteColor` / `noteColorIsChosen`.

`tintHash` and `derivedTint` STAY, against the plan: a label with no colour
of its own still derives one from its name, and that path was never the one
that failed. The mirrored pair and its fixture survive intact.

The editor follows the card, and its Done button takes the brand — the
board's compose FAB is the app's existing statement of "affirmative action
here", where Material's default secondaryContainer is a baseline colour this
theme never sets.

The colour picker is left in place, doing nothing, for exactly one step:
removing it here would leave `note.color` written by nothing and read by
nothing, which is a worse intermediate than a control that visibly does
nothing. #3041 takes the field and the picker together.

Step 1 of M315. #3148

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/src/components/NoteCard.vue

@@ -3,11 +3,10 @@ import { computed, onBeforeUnmount, ref, watch } from "vue";
 import { useNotesStore } from "../stores/notes";
 import {
   LABEL_CHIP_CLASSES,
+  NOTE_CARD_SURFACE,
   NOTE_COLOR_KEYS,
   NOTE_COLOR_LABELS,
   NOTE_SWATCH_CLASSES,
-  noteCardClasses,
-  noteTintVars,
   resolveLabelColor,
   type NoteColor,
 } from "../notes/colors";
@@ -242,37 +241,43 @@ onBeforeUnmount(() => document.removeEventListener("mousedown", onDocMousedown))
     ref="root"
     class="group relative mb-4 break-inside-avoid rounded-xl border border-[#b8b8b8] p-3 shadow-sm transition hover:shadow-md dark:border-[#404040]"
     :class="[
-      noteCardClasses(note),
+      NOTE_CARD_SURFACE,
       dragging ? 'opacity-40' : '',
       dragOver
         ? 'scale-[1.02] shadow-lg ring-2 ring-brand ring-offset-2 ring-offset-white dark:ring-offset-neutral-950'
         : '',
       active ? 'ring-2 ring-brand' : '',
     ]"
-    :style="noteTintVars(note)"
     :data-note-id="note.id"
   >
-    <!-- THE EDGE LIVES HERE, NOT IN THE PALETTE, and that is the whole point of it.
-         Every card gets the same grey hairline whatever colour it is; the fill is the
-         only thing that varies. The version of this that was a `{hue}-900` border
-         failed because the line was both the loudest element on the card (1.56-2.09
-         against its own fill, where the fill managed 1.03-1.05 against the board) AND
-         carried the same information the fill did, so a board of them read as a grid
-         of outlines. A neutral line carries no information at all, which is exactly
-         what lets it be structure.
+    <!-- THE EDGE IS THE CARD'S BOUNDARY, and since M315 it is the ONLY thing that
+         varies from the board: the fill is one neutral (NOTE_CARD_SURFACE) and no
+         longer says anything about the note. That makes this line load-bearing rather
+         than decorative — it is what a card IS.
 
-         The two values are MATCHED, not picked by eye: each measures ~1.6-1.7 against
-         the card it edges (light 1.57-1.98, dark 1.58-1.73), so the edge has the same
-         authority in either theme. #404040 is `neutral-700`, which is what the default
-         card's border always was — promoted from one entry in the palette to the rule
-         for all of them. #b8b8b8 sits between `neutral-300` and `neutral-400`, neither
-         of which lands in range: 300 fades out at 1.18 on a gray-tagged card, 400
-         jumps to 2.52 and reads as a wireframe.
+         It was already neutral before the fill was. The version that came from the
+         palette was a `{hue}-900` border and failed twice over: the line was the
+         loudest element on the card (1.56-2.09 against its own fill, where the fill
+         managed 1.03-1.05 against the board) AND carried the same information the fill
+         did, so a board of them read as a grid of outlines. A neutral line carries no
+         information at all, which is exactly what lets it be structure. The fill is
+         the same argument one size up, made two milestones later.
+
+         MEASURED AGAINST ONE FILL NOW, and deliberately left where it was. #b8b8b8 on
+         white is 1.98 and #404040 on #171717 is 1.73 — both inside the ranges these
+         values already shipped at across twenty fills (light 1.57-1.98, dark
+         1.58-1.73), but at the top of them rather than the ~1.6-1.7 the pair was
+         originally matched on. Softening the light edge to re-match would weaken the
+         only boundary a white card on a #fafafa board has, and the complaint that
+         started M315 was about fill, never about edge weight. If an operator pass
+         disagrees it is one constant, in two files.
 
          NOT a translucent black/white edge, which is the tidier-looking way to do this
-         and was measured and rejected: a border composites over the card's own fill,
-         so `border-white/20` comes out #56396d on a purple card and #a3c9c1 on a teal
-         one. Hue-coded edges are the thing being removed.
+         and was measured and rejected: a border composites over what is under it, so
+         `border-white/20` came out #56396d on a purple card and #a3c9c1 on a teal one.
+         With one fill that argument no longer bites — but an opaque grey is what the
+         Android side must also write, and two surfaces stating the same hex is how
+         they stay the same card.
 
          `shadow-sm`, back down from `shadow`: the border is the boundary again, so the
          shadow is only depth. -->