[TRACKER] Warsh riwaya abstraction

[Hetchy]

Tracking issue for generalizing the phonemizer to support a second riwaya (Warsh) alongside Hafs.

Full plan: docs/warsh-abstraction-plan.md

Why

The surface differences (different letters/diacritics for the same words, differing verse splits, word join/split) mostly arrive for free from the script. The blocker is that domain knowledge — tajweed trigger sets, special-word tables, vowel-compatibility lists, IPA literals, stop/start transforms, and the corpus shape itself — is hardcoded in Python keyed off Hafs glyphs, so a different script silently no-ops those rules. The real work is a refactor that makes riwaya context, orthography/phoneme relations, tajweed rules, and the corpus first-class and data-driven.

Principles

1. Hafs output stays byte-identical through the whole refactor (3a, 3b); new behavior only in Epic 4.
2. Domain knowledge in data, not code (no glyph/IPA/location literals in control flow).
3. One canonical internal model; the three output views project from it (no re-walks).
4. Tests before the code they protect.
5. Prove the seam on a thin slice before generalizing.

Epics

• Epic 0 — Scope & decisions
• Epic 1a — Script / Unicode / font research (+ CI validator)
• Epic 1b — Tajweed / linguistic research
• Epic 2 — Test nets (Hafs characterization + Warsh red cases)
• Epic 3a — Internal-model rework (riwaya-agnostic, byte-identical)
• Epic 3b — Riwaya abstraction seam + corpus/addressing
• Epic 4 — Warsh implementation
• Epic 5 — Wrap-up & documentation

Parallelism

1a, 1b, and the Hafs characterization net (Epic 2A) can start immediately and concurrently. The refactor (3a → 3b) is strictly sequential and gated. Epic 4 is the only place new behavior lands.

Non-goals

One riwaya / one tariq only; no qua-sdk changes here; no expert-signoff gate as a formal epic.