[LingMoe404]

Why

The reading view gives display transformers an opaque blockKey, but its reasoning DOM roots do not expose that identity. An extension adding a per-card original/translated control cannot reliably associate a visible card with the right transform request: separate blocks can have identical text, cards can move, and one reasoning card can group multiple blocks. A global toggle is not a substitute for a per-card control.

Changes

• Forward the already-existing blockKey into ReasoningStream in both transformed and untransformed paths.
• Expose that exact value as data-reader-reasoning-block-key on the reasoning text root.
• Document mounted-lifetime/opaque semantics, grouped-card handling, and the foreign-renderer boundary.
• Add five focused component-path regressions for marker/request correspondence, duplicate source text, streaming growth, transformed display and original fallback.

This does not change React keys, text, session records, layout, or the native conversation view. It adds no translation dependency and is independent of the example/docs PR #75.

Validation

• npm run typecheck: passed.
• npm test -- tests/reasoning-block-key.test.ts tests/text-transform.test.ts: 15 passed.
• git diff --check: passed.
• A broader local Windows test run encountered the existing POSIX-path assertion in tests/skill-status.test.ts; this patch does not modify that code/test.
• Local check:harness was unavailable because the Harness source-pointer configuration is absent. This is not a claim that compatibility verification passed.

The new tests use isolated hooks/presentation mocks and exercise the actual component paths and transform registry; they are not browser lifecycle or end-to-end UI tests.

This small identity seam is consumed by the independent dsh-cot-translation-reader adapter to make each card's original/translation button affect only its own reasoning blocks, without matching text or guessing DOM order.