[kesmeey]

Fixes #597.

Apply computed CSS uppercase and lowercase to extracted text in table cells, headers, list fields, and discovery previews. For example, paid styled with text-transform: uppercase is now extracted as PAID.

Respect nested style overrides and language-specific casing, including text in open Shadow DOM slots. Count transformed text against the existing byte budget. Add regression tests and update both changelogs.

Local validation

• Extension tests: 3,722 passed, 429 skipped.
• Real Chrome extraction tests: 15 passed.
• TypeScript checks and production build passed.
• Biome and Stylelint passed on an LF-normalized snapshot.
• Changelog synchronization check passed.

[NianJiuZst]

Reviewed at 0f1034d496e0b46bcb757bf92a1a8fffacd6eb00.

[P2] Follow slot assignment when resolving the casing language

caseLocaleOf() walks parentElement and the shadow host, but never follows assignedSlot. This can select the wrong language for an element assigned to a slot:

<table id="t" lang="tr">
  <tr><td><x-case><span>iı</span></x-case></td></tr>
</table>
<script>
  document.querySelector("x-case").attachShadow({ mode: "open" }).innerHTML =
    '<span lang="en" style="text-transform:uppercase"><slot></slot></span>';
</script>

In Chrome 156, the table's innerText and painted text are II, but extraction returns { "c1": "İI" }. The locale lookup reaches the light-DOM table's Turkish language instead of accounting for the slot's rendering context. The existing slot regression uses a directly assigned text node; wrapping that text in an assigned element exposes this gap.

Please account for assignedSlot in the language lookup and add a regression with different languages in the light and shadow trees, covering both directly assigned text and assigned elements. I would fix this before merging.

Validation: all 57 extraction tests passed, including the real-Chrome suite; TypeScript and Biome checks also passed. The example above reproduces the remaining mismatch using the production collector and normalizer. Validation covers the extraction modules rather than the complete extension/daemon/CLI flow.

Non-blocking scope note: explicitly transformed input and textarea values still retain their original casing in extraction. This is existing behavior on the base revision and can be tracked separately.

[kesmeey]

Reviewed at 0f1034d496e0b46bcb757bf92a1a8fffacd6eb00.

[P2] Follow slot assignment when resolving the casing language

caseLocaleOf() walks parentElement and the shadow host, but never follows assignedSlot. This can select the wrong language for an element assigned to a slot:

<table id="t" lang="tr">
  <tr><td><x-case><span>iı</span></x-case></td></tr>
</table>
<script>
  document.querySelector("x-case").attachShadow({ mode: "open" }).innerHTML =
    '<span lang="en" style="text-transform:uppercase"><slot></slot></span>';
</script>

In Chrome 156, the table's innerText and painted text are II, but extraction returns { "c1": "İI" }. The locale lookup reaches the light-DOM table's Turkish language instead of accounting for the slot's rendering context. The existing slot regression uses a directly assigned text node; wrapping that text in an assigned element exposes this gap.

Please account for assignedSlot in the language lookup and add a regression with different languages in the light and shadow trees, covering both directly assigned text and assigned elements. I would fix this before merging.

Validation: all 57 extraction tests passed, including the real-Chrome suite; TypeScript and Biome checks also passed. The example above reproduces the remaining mismatch using the production collector and normalizer. Validation covers the extraction modules rather than the complete extension/daemon/CLI flow.

Non-blocking scope note: explicitly transformed input and textarea values still retain their original casing in extraction. This is existing behavior on the base revision and can be tracked separately.

Thanks for catching this，I Fixed this problem.