icon_names subset produces glyphs with wrong stroke/fill state vs un-subset font (v345)

## Summary

When fetching Material Symbols Rounded from Google Fonts using the `icon_names=...` subsetting parameter with a large list of icons (~400 names), the resulting subset font renders glyphs at a different stroke / fill state than the un-subset full font, **regardless** of the `font-variation-settings` the consuming CSS specifies.

This appears to be a recurrence of the class of bugs already filed against `icon_names` subsetting, including:

- #1834 — "Loading only specific icons using icon_names parameter does not work properly when using the table icon" (open since 2024-11-08)
- #1818 — "Can't use star and tour icons at the same time" (open since 2024-10-17)

I'm filing a separate report because the manifestation here is "wrong glyph weight / fill" rather than "icon missing," and triggers on a different icon list. Same underlying area of code, different symptom.

## Versions involved

- Material Symbols Rounded internal Google Fonts version: `v344` → `v345`
- Bug observable starting on/around 2026-05-22 → 2026-06-02 (matches the public [Material Symbols Changelog](https://material-symbols-changelog.vercel.app/) update window).
- The bug is in the **subsetted** font response. The un-subset (full) font fetched from `fonts.gstatic.com/s/materialsymbolsrounded/v345/...` renders correctly at both v344 and v345.

## Reproduction

Two minimal HTML files. Both request the same family, axes, and CSS — the only difference is the presence of `&icon_names=...`. Open both side by side in the same browser.

### A — uses icon_names (broken)

```html
A — subset

.btn{display:inline-grid;place-items:center;width:36px;height:36px;border-radius:999px;background:#234;color:#fff}
.icon{font-family:'Material Symbols Rounded';font-weight:normal;font-size:20px;line-height:1;
-webkit-font-feature-settings:'liga';-webkit-font-smoothing:antialiased;
font-variation-settings:'FILL' 0,'wght' 300,'GRAD' 0,'opsz' 24}

settings
question_mark

```

The full icon list I used (alphabetical, ~400 names) is available [in this gist or PR / I can attach if useful]. A small two-icon list (just `settings,question_mark`) does **not** reproduce the bug — it requires a large icon set.

### B — no icon_names (correct)

Same HTML as A, but the stylesheet link drops `&icon_names=...`:

```html

```

### Observed difference

The cog (`settings`) glyph in A renders with a noticeably thinner stroke / lower visual weight than in B, even though both ask for `'wght' 300, 'FILL' 0` and both ultimately resolve to the same family. The `?` (`question_mark`) glyph is harder to distinguish visually.

The Network panel confirms different font paths:

- A: `fonts.gstatic.com/l/font?kit=…&v=v345` (size ~570 KB) — the "l" dynamic-subset path.
- B: `fonts.gstatic.com/s/materialsymbolsrounded/v345/...` — the "s" canonical full-font path.

## Direct font inspection (fontTools)

The subset font is structurally identical in shape between v344 and v345, just with +9 ligatures (matching the public changelog):

```
v344 woff2: 567,284 bytes, sha 7c18d84d96fa350ec33c2f4bc0080babd52a8785
cmap=31 chars, 4064 ligatures, features [rclt, rlig]
v345 woff2: 570,032 bytes, sha af3433aee2663cc9f14c65efdec9650e186e7c7c
cmap=31 chars, 4073 ligatures, features [rclt, rlig]
```

Both have the same OpenType table shape; what changed between v344 and v345 in the subsetted woff2 is the `glyf` / `gvar` / variation-axis data, in a way that interacts with our requested axes and produces wrong rendering.

## Why this matters

This bug is shipping to production for any app that uses the documented `icon_names` subsetting parameter (recommended by your [Material Symbols guide](https://developers.google.com/fonts/docs/material_symbols#optimizing-with-the-icon_names-property)) with a sufficiently large icon list. The bug is non-deterministic-from-the-app's-perspective: a Google-side font version rollout can break a deployed product without any change in the app's repo. Build pipelines that inline Google Fonts CSS at build time (e.g. Angular CLI's `optimization.fonts: true`) bake the broken subset into the production artifact.

We've worked around it by removing `icon_names` from our font request and accepting the larger full-font payload. Self-hosting is our follow-up. But this should be a real fix on Google's side, given the documented `icon_names` feature is supposed to be safe.

## What would help

- Acknowledgment of the bug.
- Either a fix in the `icon_names` subsetter, or a documented disclaimer on the [Material Symbols guide](https://developers.google.com/fonts/docs/material_symbols) noting that the `icon_names` subset can render axes differently than the full font.
- Optionally: an opt-out parameter to force `font-variation-settings`-honoring behavior in the subset.

## Cross-references

- #1834 (open, 2024-11-08)
- #1818 (open, 2024-10-17)
- Material Symbols Changelog showing the v344→v345 window: https://material-symbols-changelog.vercel.app/

Start with the two minimal HTML reproductions and compare the subsetted and full font responses in the Network panel. Inspect the v344 and v345 WOFF2 files with fontTools, focusing on the glyf, gvar, and variation-axis data described in the report. Done means the icon_names subset honors the requested axes like the full font, or the guide documents the limitation and an available opt-out.

Written by the indexing model from the issue text.