fix(activity): scope count helper and phone pod grid

[lilyshen0722]

Summary

• scope Activity helper copy to all-pods vs selected-pod mode
• keep the numeric count in the heading and preserve count-unavailable state
• retain the rail track on phone pod routes while feature-wide pages stay single-column

Verification

• src/v2/__tests__/V2ActivityPage.test.tsx (35/35)
• src/v2/__tests__/v2-layout-invariants.test.ts (102/102)
• git diff --check

UX owns 390px/900px browser verification.

[lilyshen0722]

UX-GATE: APPROVED @ 6701fb0 — phone pod width corrected; Activity and exact-source routes verified at 390 and 900px.

Production build with mocked authentication/API responses, including a real browser context with hasTouch/isMobile at 390. Source activation used keyboard Enter. At 390, main pane and chat each measure 390px; #message-2032 is 302px wide, visible at y422–473 inside the y51–788 scroller, and focused. At 900, main/chat measure 528/526px and the focused source is fully inside the scroller. No horizontal overflow. Activity retains its 390/800px-wide, 52px-high header; global 65/50 and scoped 9/9 show the distinct approved helper strings. EN/ZH source copy and unchanged countUnavailable reviewed.

This supersedes the 6124f23 browser failure: hidden rail with two columns left the main/chat at 56px and source at zero width. No count wiring changes. This is a PR build gate; live verification still awaits deployment. No live account actions or source implementation performed.

[lilyshen0722]

UX-GATE: APPROVED @ 10a16e9 — rebuilt and repeated Activity and exact-source pod geometry at 390 and 900px.

390: Activity main 390px, pod main/chat 390px; focused #2032 is 302px wide at y397–448 within scroller y51–788. 900: Activity main 802px, pod main/chat 528/526px; focused source 418px wide at y419–470 within scroller y66–823. Both helpers match the approved wording with global65/50 and scoped9/9. No horizontal overflow.

The prior 6701fb0 browser also showed Activity at full width; this delta preserves that measured behavior. This production PR build uses mocked auth/API and a hasTouch/isMobile browser context at 390. Source activation is keyboard Enter, not a physical tap. Live verification remains pending deployment. No live writes or implementation edits.

[lilyshen0722]

Gate at 10a16e9. Layout is correct and matches the pre-regression baseline. One defect remains in the guard, unchanged across three revisions of it.

Layout, measured in a browser

At 390px, every shell variant — .v2-shell, --feature, --no-inspector, --feature-wide — computes grid-template-columns: 390px with the rail at display: none and a 390px main pane. That matches pre-#1588 (c386625) exactly, and the comment above the rule ("Rail and pod list are drawers") is now true of the sheet.

At 900px, --feature-wide is still 56px 802px, so the Activity pane ac67890 exists to protect is intact; pod and feature routes keep the three-track tablet layout.

Progression across the heads, same fixture: pre-#1588 390px → main 56px 260px 74px → 6124f23 56px 334px → 10a16e9 390px.

Blocking-ish: the guard cannot see the value it pins

/\.v2-shell:not\(.v2-shell--feature-wide\),\s*\.v2-shell--feature-wide\s*\{[\s\S]*?grid-template-columns: minmax\(0, 1fr\);/

[\s\S]*? crosses the closing brace, so when this rule's own declaration changes the scan continues into the next rule — .v2-shell, .v2-shell--no-inspector, .v2-shell--feature { grid-template-columns: minmax(0, 1fr); — and matches there.

Measured at this head: changing the collapse rule to var(--v2-rail-w) minmax(0, 1fr), which restores the rail track on every phone shell and is the layout rejected two revisions ago, leaves the suite at 102/102 green.

Bounding the match to the rule body fixes it, verified rather than proposed: replacing [\s\S]*? with [^}]*? keeps the control at 102/102 and turns that mutation red.

This is the third revision of this guard and the third instance of the same defect — ac67890 asserted the tablet rule's presence while its cascade weight was what changed; 6124f23 asserted a single-column rule the sheet no longer honoured; this asserts a value it reads from a neighbouring selector. The guard has never yet been able to fail for the reason it exists.

Otherwise correct

• .v2-pane--rail { display: none; } is asserted and true at 390px, so the collapsed track and the hidden rail are pinned together.
• Deleting the collapse rule reddens 1; reverting the 1023 rule to bare .v2-shell (the ac67890 shape) reddens 1.
• Copy verified at 6124f23 and carried — the deltas since touch only v2.css and this test. Control 137/137 here; collapsing scopedCountDescription onto countDescription reddens 1, so the fixture separates the two modes. Both locales in one commit, countUnavailable untouched.

Clear from me once the regex is brace-bounded. Everything else measured green.

[lilyshen0722]

Operator gate at a855a96: the only delta from UX-approved 10a16e9 is the reviewer-requested brace-bounded regex in the layout invariant. Application files are identical, so the measured 390px/900px UX evidence carries. Sprint Review explicitly cleared the change conditional on that exact assertion correction and verified the control/mutation pair. Owner reports 137/137 focused tests. All branch commits are Lily-authored.

Merge remains gated on final-head CI. After Deploy Dev completes, verify the real authenticated phone pod/source route and the scope-specific helper copy; the PR browser evidence used mocked auth/API.

[lilyshen0722]

Cleared at a855a96. The one item from my 10a16e9 gate is fixed and the guard now discriminates.

Measured here

Control: v2-layout-invariants + V2ActivityPage + v2-type-floors = 142/142.

mutation	at 10a16e9	at a855a96
collapse rule → var(--v2-rail-w) minmax(0, 1fr) (the rejected rail track)	green — invisible	1 red
delete the collapse rule	1 red	1 red

Bounding the match with [^}]*? stops the scan crossing the closing brace, so the assertion now reads the declaration belonging to its own selector instead of borrowing one from the next rule. That was the whole of my outstanding condition and it is a one-line, test-only change on top of the frozen head.

Carried, with the basis stated

• Layout (browser, 10a16e9; v2.css is byte-identical at this head, the delta is the test file alone): at 390px all four shell variants compute a single 390px track, .v2-pane--rail resolves to display: none, and the main pane's rect is 390px. At 900px --feature-wide is 56px 802px, so the Activity pane ac67890 protects is intact. This matches pre-#1588 (c386625) exactly.
• Copy (mutation, 6124f23; the locale files and V2ActivityPage.tsx are unchanged since): collapsing scopedCountDescription onto countDescription reddens 1, so the fixture separates the two modes rather than passing on either. Both locales in one commit; countUnavailable untouched.

Nothing outstanding from me. The browser pass on the mounted app remains ux-lead's — my fixture is synthetic markup with the real class nesting, which rules out the CSS reserving a track but cannot rule out a constraint inside the chat or source components.