feat(database): add public game data registries

docs/DESIGN_SYSTEM.md

@@ -1183,6 +1183,68 @@ back to a short orange text mark rather than removing the relationship.
 Use this pattern only for small bounded sets that remain scannable, such as the
 two-to-four compatible Brand Sets on Gear. Long or unbounded relationships
 continue to use counts, searchable inspection, or expanded detail views.
+Public Gear cards use the same rail for compatible Brand Sets and available
+Talents so players can identify actual options instead of reading a count.
+Each icon retains its accessible name and hover title, and missing artwork uses
+the shared placeholder without suppressing the relationship. Relationship
+icons are buttons: activating one opens a modal quick view using the same card
+facts as that record's public database category. The overlay closes through
+its explicit close action, backdrop, or Escape key. Do not render an empty
+Talent rail on item types that cannot equip Talents.
+
+### Public game-database registries
+
+The public Database is a player-facing reference surface, separate from the
+ISAC editing workflow. Its index exposes eight durable categories: Gear,
+Weapons, Weapon Mods, Gear Mods, OS Protocols, Talents, Brands, and Skill
+Chips. Attributes are implementation vocabulary resolved into the facts and
+effects shown on those records; do not promote Attributes to a public
+top-level category.
+
+Each index category is a fully interactive square registry card with a live
+approved-record count, concise scope statement, visible hover/focus state, and
+pressed feedback. A category page uses the shared compact category rail,
+live name search, pagination, and a responsive card grid. Record cards use the
+same hierarchy:
+
+- a fixed icon cell and compact identity header;
+- small textual badges for quality, tier, or exceptional state;
+- bordered fact cells for primary values;
+- relationship lines and tier descriptions only when applicable.
+
+When a record represents an ordered progression rather than independent facts,
+use the stacked fact treatment. Brand Set bonuses are shown vertically in
+two-, three-, then four-piece order; do not add a redundant “3/3 bonuses”
+badge when all three rows are already visible.
+
+Record cards may end with contextual actions that connect related public
+registries. Actions use the compact orange tactical-button treatment and
+encode their destination filter in the URL. Brand cards provide a “find Gear”
+action that opens the Gear registry with that Brand selected; the same action
+must remain available in Brand quick views.
+
+Cards display canonical active data only. Attribute references must be
+resolved to readable names, values, and units instead of exposing IDs or raw
+JSON. Missing uploaded art uses the standard missing-item placeholder.
+Desktop layouts use three record columns, intermediate layouts use two, and
+narrow layouts use one. The eight-category rail reduces from eight to four to
+two columns. Preserve keyboard focus, pressed feedback, reduced-motion
+behavior, and readable textual state in every layout.
+
+Category-specific discovery uses the shared tactical filter matrix. Filters
+apply immediately, remain encoded in the URL, reset pagination, and compose
+with name search. Multiple selections inside one facet are inclusive (`OR`);
+active facet groups combine restrictively (`AND`). For example, selecting two
+Brands and four Talents returns Gear matching any selected Brand and any
+selected Talent. Never implement multi-select facets as an implicit match-all
+within the same group.
+
+Use segmented icon choices for bounded visual vocabularies of six or fewer,
+such as Gear slots. Use the matching searchable multi-select list for growing
+sets such as Brands and Talents. Always expose selected counts, a single clear
+action, `aria-pressed` state, keyboard focus, and explicit text explaining the
+combination rule. At intermediate width, the bounded facet spans the row above
+two searchable facets; on narrow screens all facet groups stack vertically.
 
 ### Build persistence and sharing