feat(database): refine weapon registry cards

docs/DESIGN_SYSTEM.md

@@ -1217,6 +1217,13 @@ 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.
 
+Weapon cards also use stacked facts. Their level-50 Damage range is the primary
+fact: a taller orange-railed row with enlarged values and the Damage Type in
+the label. Public damage is calculated from the stored level-1 endpoints using
+the same `weaponBaseRange` curve as the builder; never label the configured
+base endpoints as level-50 values. Weapon Talent 1 and Talent 2 pools use
+separate clickable icon rails and the standard Talent quick view.
+
 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”
@@ -1253,6 +1260,13 @@ the talent name is unknown. Brand facets similarly index the names of all
 set-bonus Attributes, allowing players to search by the desired mechanic
 without exposing that metadata as extra visual clutter.
 
+Public database command headers are content-sized and must explicitly override
+the global 76-pixel site-header rule. Their eyebrow, title, description, count,
+and index action remain inside the bordered command surface at every scale.
+Children use `min-width: 0`, long titles may wrap, and category navigation
+tracks use zero-minimum grid columns so translated or enlarged text cannot
+force horizontal page overflow.
+
 ### Build persistence and sharing
 
 The builder distinguishes device persistence from account persistence. `SAVE
@@ -1335,3 +1349,25 @@ into per-item storage. A later contributor replaces it through the normal icon
 upload proposal, preserving the canonical record and audit history. The upload
 itself retains all transparent-format, size, SVG-safety, focus, drag/drop, and
 paste validation requirements.
+
+### Public database performance facts
+
+Use the shared `DatabaseFacts` renderer for registry-card performance data and
+quick views. Weapon identity headers keep the native tier beside the category
+identity as a compact textual `T0`, `T1`, or `T2` marker. Place tier and the
+smaller damage-type icon in a dedicated top-right status cluster; do not
+interrupt the readable `category // damage type` metadata with icons. Reserve
+the emphasized first fact for the weapon's damage range, pair it with the
+canonical damage-type icon, and render the calculated level as a subdued
+annotation rather than part of the primary label. Public level-50 damage must
+be calculated from the stored level-1 endpoints with `weaponBaseRange`; never
+relabel raw source values.
+
+Represent bounded handling values such as Accuracy and Stability with compact
+horizontal meters. Always retain the numeric value and an accessible
+`value out of 100` label so the graphic does not carry meaning alone. Use the
+stable sequence `label → meter → exact value`, with the exact number aligned in
+a dedicated column to the right of the graphic. Clamp display values to
+`0–100`, use orange only for the filled measure, and keep the unfilled track
+neutral. Stack meter labels and tracks on narrow cards rather than shrinking
+them below a reliably readable width.