Soften session lineage count badge

[Michaelyklam]

Summary

• change the session lineage count badge from X segments to softer X prior turn(s) copy in the English base locale
• keep the existing lineage expand/collapse behavior and accessibility attributes untouched
• add a focused regression test for the English badge label so the old visible segments wording fails

Refs #2155

Verification

• git diff --check
• python -m py_compile api/*.py server.py
• pytest -q tests -k "session or sidebar or lineage"

[nesquena-hermes]

Pulling the worktree and reading the i18n diff at cron-pr-2175/static/i18n.js:686-692 against the existing tracking on #2155. Cross-referencing with #2155's discussion (PR #2072 — hold,ux — is the structural fix; #2155 is explicitly the copy follow-up). The English-only soft-rename is a reasonable narrow slice if it's positioned correctly in the changelog.

Code reference

static/i18n.js:686-692 (master) — the English base locale:

session_meta_messages: (n) => `${n} msg${n === 1 ? '' : 's'}`,
session_meta_children: (n) => `${n} child${n === 1 ? '' : 'ren'}`,
session_meta_segments: (n) => `${n} segment${n === 1 ? '' : 's'}`,

The PR rewrites only the third line to ${n} prior turn${n === 1 ? '' : 's'}.

What I'd flag

1. The 10 other locales still say "segment". grep -n session_meta_segments static/i18n.js shows 11 entries — it (italian), ja (セグメント), ru (сегм.), es (segmento/s), de (Segment/e), zh (段), zh-Hant (段), pt (段 — actually this is a bug already, see below), ko, fr. The English fix doesn't propagate. A non-English user reads the same technical label Consider hiding or softening the 'X segments' badge in the session sidebar #2155 was filed about. Recommend either fixing all 11 in this PR, or explicitly punt the other locales to a follow-up issue and call it out in the PR body. The current state — fix English, leave 10 broken — is the inconsistent middle that Localize Logs panel i18n keys (5 keys × 8 non-English locales — TODO placeholders from PR #2085) #2098-style locale gaps were just cleaned up in PR Localize logs severity filters #2161.

2. There is a pre-existing bug at line 8138. The pt (Portuguese) locale block has session_meta_segments: (n) => \${n} 段`,` — that's the Chinese character, almost certainly a copy-paste from the zh block above it. Worth fixing in this PR while we're touching the file. Same with line 7950 (zh-Hant inherits zh's '段' which is fine but coincidentally identical).

3. The regression test is brittle. tests/test_session_lineage_collapse.py:404-429:

   first_lang = i18n_text.index("_lang: 'en'")
   second_lang = i18n_text.index('_lang:', first_lang + 1)
   english_slice = i18n_text[first_lang:second_lang]
   ...
   match = re.search(r"session_meta_segments:\s*(\(\w+\)\s*=>\s*[^,]+)", english_slice)

   Two failure modes:

   • The [^,]+ greedy match stops at the first comma. The arrow body \${n} prior turn${n === 1 ? '' : 's'}`contains no comma so it works *today*, but the moment someone adds anIntl.PluralRules`-style helper with a comma inside the template literal, the regex silently captures a truncated value.
   • The _lang: 'en' literal match assumes single-quoted, no-whitespace formatting. If the file ever gets prettier'd or switches to double quotes, the test breaks loudly but for the wrong reason.

   The intent is right (assert "segment" doesn't appear in the English value), but a cleaner expression is to import static/i18n.js semantically via the parser already in tests/test_localization_completeness.py (or wherever the existing locale walker lives) and assert on the rendered value of LOCALES.en.session_meta_segments(1) and (2). That's resilient to formatting changes.

On the broader UX call

Worth restating from #2155's thread: PR #2072 ("Show session lineage indicators" toggle, hold,ux) is the structural lever. Renaming "segments" to "prior turns" softens the label but does not address the maintainer's underlying question on #2155 — should the badge be visible by default at all. If the answer to that question turns out to be "default off," this rename is wasted churn. If it's "default on, just softer copy," this PR is the right slice.

Either way the English-only fix lands cleanly modulo the test brittleness above. I'd block the merge briefly to either fix all 11 locales together, or be explicit in the PR body that this is intentionally English-only and the other locales are tracked separately. The PR's CHANGELOG/refs description doesn't mention either way today.

[nesquena-hermes]

Correction on point 2 above: I mis-read the locale blocks. Line 8138 is inside the zh-Hant block, not pt. The pt block's session_meta_segments is at line 9168 (${n} segment${n === 1 ? '' : 's'}), which is the English fallback you've also seen elsewhere — that one is technically translatable to Portuguese (segmento/s, which line 4853's es block uses).

So points (1) and (3) stand — the English-only rename leaves 10 locales saying "segment" (or its localized equivalent), and the regex test is brittle — but there is no pt-uses-Chinese-character bug to fix here. Apologies for the noise.