fix(cli): flag text with an effectively transparent fill in check

Wild report (5th in cluster, CLI 0.7.53): snapshots omitted all text while
check passed — text painting with a transparent -webkit-text-fill-color (which
overrides `color` for the glyph fill AND inherits, so a parent's transparent
fill silently blanks descendant text that has its own opaque `color`) renders
invisible, but every geometry/occlusion/contrast audit missed it. Contrast in
particular reads `color`, not the fill that actually paints, so white-`color`
+ transparent-fill text scored as high-contrast and passed.

Add an invisible-text detector to the layout audit: flag any text element whose
effective fill (computed -webkit-text-fill-color, which already resolves to
`color` when unset) is transparent. Gradient/clipped text (background-clip:text)
legitimately uses a transparent fill and is excluded. Verified: check now fails
on an inherited-transparent-fill fixture (text_not_painted) while gradient text,
body-inherited color, sub-composition color, and real registry examples stay
clean.

packages/cli/src/utils/checkBrowser.ts

@@ -946,6 +946,7 @@ const LAYOUT_ISSUE_CODES: readonly LayoutIssueCode[] = [
   "container_overflow",
   "content_overlap",
   "text_occluded",
+  "text_not_painted",
   "caption_zone_collision",
   "frame_out_of_frame",
   "motion_appears_late",

packages/cli/src/utils/layoutAudit.ts

@@ -16,6 +16,7 @@ export type LayoutIssueCode =
   | "container_overflow"
   | "content_overlap"
   | "text_occluded"
+  | "text_not_painted"
   | "caption_zone_collision"
   | "frame_out_of_frame"
   // Frozen-sweep guard (#U10) — a whole-run meta-finding, not a per-sample