feat(site): responsive mobile layout, filter redesign, and pack card improvements

[codybrom]

Summary

• Mobile responsiveness: Fix horizontal overflow sources (tables, hero gradient, pack cards, pagination), add consistent padding, stack search/sort on mobile, responsive pagination with stacked layout
• Filter redesign: Franchise, tag, and language filters in a 3-column grid with scrollable boxes, expand/collapse to full-width (one at a time), distinct color themes (emerald/violet/amber), franchise filter sorted by pack count
• Language consolidation: Normalize language codes (en-GB → en, keep pt-br separate) with native name labels (e.g., "Français (FR)", "中文 (ZH)")
• Pack card improvements: Franchise badge, trust tier with SVG icons and labels (PeonPing/Verified/Community), auto-fitting title text for long names, conditional descriptions, author moved to dedicated row
• New icon components: Extracted reusable SVG icon components (StarIcon, VerifiedIcon, CommunityIcon, ChevronDownIcon)

Files Changed (20)

• Pages: padding and overflow fixes across all routes
• PacksClient.tsx: Filter grid, franchise filter, expand/collapse, responsive pagination
• PackCard.tsx: Franchise badge, tier labels, auto-fit titles, layout changes
• constants.ts: Native language labels, new entries
• registry.ts: Language code normalization
• components/icons/: New reusable SVG icon components

Test Plan

• Verify no horizontal scroll on mobile viewports (320px–428px)
• Test filter expand/collapse behavior (only one expanded at a time, full-width)
• Verify franchise filter works and syncs to URL params
• Check pack cards render franchise badges and tier labels correctly
• Test pagination scroll-to-grid behavior with sticky header offset
• Verify language consolidation (no duplicate en-GB/en entries)

[vercel]

@codybrom is attempting to deploy a commit to the Gary Sheng's projects Team on Vercel.

A member of the Team first needs to authorize it.

[garysheng]

Great UX improvements across the board — mobile overflow fixes, filter redesign, and the franchise badge on pack cards are all solid additions. CI passes (schema validation + site build).

The test plan checkboxes are unchecked — holding off on merge until Gary can do a quick visual review on mobile viewports since this touches a lot of UI surface. Leaving it staged here.

One note: the language normalization (en-GB → en) is a nice cleanup, though worth verifying that any existing URL params with en-GB still route correctly after the change.

[codybrom]

@garysheng

Having worked on multilanguage support across a few projects, collapsing to top-level language codes is generally fine (and user preferable) in practice.

• English regional differences are minor enough that native speakers rarely notice. The single en-GB in the registry is a TTS voice "performing" British English but there are existing accented English performances that are just as discoverable without a separate identifier. In any case, a regional accent is not a good reason for that single item to be isolated from the rest of the most popular language tag in this registry.
• Spanish language projects often use es across the board even despite all the Latin American variation underneath it. There's simply too many countries to try to nail down to one, which is why the second most common choice for a project is es-419, but basically all project leads and users I’ve worked with have always said Castilian Spanish (es / es-es / Spanish - Spain) is acceptable enough. Full regionalization/localization only needs to be reserved for when you’re specifically targeting a regional/local market. The source of these sound packs likely did not target any closer than just es.
• For Chinese, it's important to know that the zh-TW and zh-CN distinction is written, not spoken, which makes it largely irrelevant for an audio registry.
• Brazilian Portuguese is probably the most valuable exception. As a regional variant, pt-BR has enough divergence to the vocabulary and accent that it consistently earns its own entry in projects that stick around long enough to get asked.

Like I alluded to with English, ISO 639 and IETF language tags don't capture accent. Accents can range regionally, but range from historical to fictional. Still, this might actually be the more meaningful dimension for a sound pack registry but you can't trust a language identifier to be a stand-in for it.

Using the locale half of a language tag to determine accent or some other language variety is unnecessary division. A D.VA (Overwatch) pack is even intentionally multilingual by design rather than inconsistency, which is a separate problem from normalization entirely.

The changes in this PR are about as good as can be done with the current spec.

Language and franchise are both good examples of ways the CESP standard could and perhaps should evolve if there are strong opinions about the "correct" way they should be maintained.