[FIR-317] Align the flydocs badge neutral chip with the warm ramp

apps/playground/src/app/themes/_flydocs-theme-dark.scss

@@ -57,4 +57,9 @@
   --ff-color-error-50: color-mix(in srgb, #dc2828 22%, #161826);
   --ff-color-warning-50: color-mix(in srgb, #e59a07 22%, #161826);
   --ff-color-info-50: color-mix(in srgb, #3b59f5 22%, #161826);
+
+  /* `initial` is the guaranteed-invalid value on `:root`, so the badge's
+     `var(--ff-badge-neutral-bg, var(--ff-color-neutral-100))` falls through
+     to the dark neutral repin instead of the light warm pin above. */
+  --ff-badge-neutral-bg: initial;
 }

apps/playground/src/app/themes/_flydocs-theme.scss

@@ -56,6 +56,11 @@
   --ff-color-neutral-700: #363b4e;
   --ff-color-neutral-900: #161826;
 
+  /* Neutral badge-chip background: Flydocs' warm neutral-chip role
+     (`--hub-sys-color-neutral-subtle` → `--hub-ref-color-warm-50`),
+     consumed by ff-badge as `var(--ff-badge-neutral-bg, …)`. */
+  --ff-badge-neutral-bg: #f6f3ec;
+
   /* ---- Primary (brand blue) ----
      -600 is consumed only for accent/indicator roles (never text
      contrast), so it follows Flydocs' own "hover pinned to base"

docs/flydocs-parity-report.md

@@ -33,7 +33,7 @@ zoom**.
 | Wave | Component | States captured | Verdict |
 |---|---|---|---|
 | 1 | `ff-icon` | 5 registry icons × sm/md/lg, light+dark | ✅ Pass |
-| 2 | `ff-badge` | color × xs/sm, dot, pill/square | ⚠️ Pass with one flagged delta (neutral chip) |
+| 2 | `ff-badge` | color × xs/sm, dot, pill/square | ✅ Pass (neutral chip delta resolved, see FIR-317) |
 | 2 | `ff-avatar` | initials × sm/md/lg | ✅ Pass |
 | 2 | `ff-skeleton` | text/rect/circle | ✅ Pass |
 | 2 | `ff-progress` | 25/60/90, labelled | ✅ Pass |
@@ -52,18 +52,10 @@ zoom**.
 
 Per the gate's contract, components that fail the comparison are **not**
 fixed inside FF-CAT-20 — each perceptible delta generates its own issue.
-Two deltas are flagged; both are borderline-perceptible and pre-documented
-in the equivalence doc:
+One delta is flagged, borderline-perceptible and pre-documented in the
+equivalence doc:
 
-1. **Neutral badge chip runs cool, Flydocs' runs warm.** The design system
-   reuses `--ff-color-neutral-100` (cool grey, `#eef0f5`) for the neutral
-   chip background, while Flydocs' own neutral chip role points at the warm
-   ramp (`--hub-ref-color-warm-50`, `#f6f3ec`). Every *other* consumer of
-   that stop (hover backgrounds, dialog/toast chrome) matches Flydocs with
-   the cool value, so the ramp-position value was kept. Perceptible only
-   with both chips side by side; needs a product-owner call on whether the
-   neutral badge deserves its own component token.
-2. **Input focus ring: solid outline vs translucent halo.** Flydocs models
+1. **Input focus ring: solid outline vs translucent halo.** Flydocs models
    focus as a translucent box-shadow ring (brand blue at 25% alpha);
    `ff-input` consumes `--ff-color-border-focus` as a solid 2px outline on
    the field wrapper (`:focus-within`, after the FIR-289 refactor moved it
@@ -73,6 +65,18 @@ in the equivalence doc:
    ring-style focus treatment — a component change, out of this gate's
    scope.
 
+## Resolved deltas
+
+- **Neutral badge chip runs cool, Flydocs' runs warm — resolved (FIR-317).**
+  `ff-badge`'s neutral chip background now resolves through its own
+  component token, `--ff-badge-neutral-bg` (falling back to
+  `--ff-color-neutral-100` when unset), and the Flydocs theme pins it to
+  the warm ramp value its own neutral-chip role uses
+  (`--hub-ref-color-warm-50`, `#f6f3ec`). Every other consumer of
+  `--ff-color-neutral-100` (hover backgrounds, dialog/toast chrome) is
+  unaffected. See `docs/flydocs-theme-token-equivalence.md` for the full
+  reasoning.
+
 ## Known gaps (not diffs)
 
 - **No `ff-textarea`** — wave 5 lists textarea (`hub-textarea`, 14 uses in

docs/flydocs-theme-token-equivalence.md

@@ -104,14 +104,17 @@ Matched position-for-position:
 All **direct** (Flydocs' neutral ramp has extra stops at 0/25/950/1000 that
 the design-system doesn't consume; every consumed step lines up 1:1).
 
-Caveat: `--ff-color-neutral-100` is also the only stop the design-system
-reuses for `ff-badge`'s "neutral" chip background. Flydocs' own neutral chip
-role (`--hub-sys-color-neutral-subtle`) actually points to the *warm* ramp
-(`--hub-ref-color-warm-50`, `#f6f3ec`), not the cool neutral-100 used
-everywhere else this stop appears (hover backgrounds, dialog/toast chrome).
-Since the cool-neutral role dominates by consumer count, the ramp-position
-value was kept; the ported neutral badge will read slightly cooler than
-Flydocs' own chip.
+Caveat: `--ff-color-neutral-100` is the stop every *other* consumer of the
+neutral badge's former background reuses (hover backgrounds, dialog/toast
+chrome), and it stays the ramp-position value there. `ff-badge`'s "neutral"
+chip background is the one exception: it now resolves through its own
+component token, `--ff-badge-neutral-bg` (falling back to
+`--ff-color-neutral-100` when unset), which this theme pins to `#f6f3ec` —
+the warm ramp value Flydocs' own neutral chip role
+(`--hub-sys-color-neutral-subtle`) points to (`--hub-ref-color-warm-50`).
+Dark mode intentionally leaves `--ff-badge-neutral-bg` unset (the source
+product's dark theme does not repin its neutral-chip role either), so the
+dark badge falls back to `--ff-color-neutral-100`'s own dark repin.
 
 ### Primary (brand blue)