Divider and border weight (k6shr)

Two related fixes to how a Divider (src/tui/components/Divider.tsx) sits next to the chrome around it, documented in full beside the accent budget and the spacing scale in src/tui/theme.ts:

1. dim is opt-in, never unconditional. Divider used to (before k8ev5) or could regress to applying dimColor unconditionally, which is why a focused pane's own rule rendered as a DIM orange line instead of a full-strength one — indistinguishable from the resting state on many terminals. Divider now takes an optional dim prop, defaulting to false; a caller passing an explicit color (a focused pane's frame, a state-coloured rule) is painted at full strength unless it explicitly asks to recede.
2. The rule glyph is the LIGHT weight. Divider drew SYM.hbar (U+2501, heavy) while chromeBorder's 'round' edges draw the light weight (U+2500-family) — the rule visually out-weighed the chrome beside it. Divider now draws the new SYM.hbarLight (U+2500) catalogue glyph, matching chromeBorder's edge weight (the same call Markdown's HrRow and FleetList's kzqnq comment already made for the same reason). SYM.hbar stays in the catalogue for a genuine status-bar-weight rule; nothing draws one today.

Separately, WelcomeBanner's hub layout (the cyberine agents first-run welcome) used to open with its own full-width <Divider color={ACCENT}/> directly under AppHeader's own closing border — two rules closing one seam, the second one ACCENT-heavy on top of being redundant. That leading divider is removed from both the wide and the narrow (< 70 columns) hub layouts; the content now sits directly under the header, the way any content sits under a bordered chrome region.

Run recipe:

npm run selftest:divider-weight   # offline; renders Divider + AppHeader + WelcomeBanner through Ink

The guard renders Divider in isolation to confirm the default carries no dimColor sequence and draws the light glyph, that an explicit color is never dimmed, and that dim={true} is reachable and actually emits it — then renders AppHeader immediately followed by the hub WelcomeBanner (the same composition app.tsx uses) and asserts no two rule rows land back to back once blank/margin rows between them are discounted, i.e. no region gets closed by two rules.

Known Limitations and Deferred Work. The "no region closed by two rules" check is scoped to the one composition that actually had the bug (AppHeader + the hub WelcomeBanner); it is not a general sweep of every screen in the TUI for accidental doubled rules. dim has no current caller — it exists so a future one that genuinely wants a receded rule does not have to reach for dimColor directly and reintroduce the unconditional shape by hand.