fix(citation): recognise English-canonical OF books, verse sub-letters

35% of OF citation fields (259/730 on colitur readings --rite of 2026)
printed unconverted -- 1 John renders on 2 January but not 3 January.
Two independent causes, both in the citation/siglum path, neither in
the OF data itself:

1. Book.table only ever surveyed the three EF citation-bearing files,
   so 345 references citing a book no EF file happens to use (Job,
   Ruth, Judges, 1/2 Samuel, 1/2 Chronicles, 1/2 Maccabees, Baruch,
   Ecclesiastes, Habakkuk, Haggai, Nahum, Zechariah, Zephaniah,
   Deuteronomy, Amos, Micah, Lamentations, Ezra, Joshua, 2/3 John,
   Jude, Philemon, plus "Isaiah"/"Jeremiah"/"Ezekiel"/"Malachi"/"Mat"/
   "The Acts"/"Tobit"/"Song of Solomon" spelling variants of books EF
   already knows) failed as "unknown book". Added as a new, separate
   of_lectionary_table rather than folded into the EF-surveyed table:
   none of these 25 new books is attested in the EF's own scans, and
   lang/la.ini's own header refuses to fabricate an uncited Latin
   title, so they are resolvable (parse + render, falling back to
   their own English spelling) but deliberately excluded from Book.all
   -- test_lang_coverage.ml's la.ini-completeness promise is preserved
   exactly for the ids it already covered, not silently weakened.

2. Parse's grammar could not read a verse number carrying a lectionary
   sub-verse letter ("11a", "1bcde") at all -- the dominant remaining
   failure shape once (1) was fixed. verse_range now carries a
   verse_num { n; suffix } on each boundary, PRESERVED through
   rendering rather than dropped (dropping would silently lose real
   precision the source text carries). Chapter numbers are untouched
   (nothing in the data ever attaches a letter to one).

A third, subtler bug surfaced by (1): registering "jude"/"philemon"/
"2 John"/"3 John" exposed Parse's existing "leading comma-number is a
chapter" heuristic misreading a single-chapter book's bare verse list
("Jude 17,20b-25") as chapter 17 -- a wrong PARSE, worse than the
previous safe "unknown book" failure. Book.is_single_chapter now tells
Parse to skip that heuristic for the four one-chapter books and default
to chapter 1.

Residual, honestly enumerated rather than forced to zero: 41 distinct
references (of 1540) are hyphenated ranges crossing a chapter boundary
("2:29-3:6") -- a Parse.t shape verse_range/part do not represent, a
type restructuring deliberately not attempted this task. Pinned exactly
by the new test_citation_coverage_of.ml, both directions (a new failure
or one of these 41 starting to convert both go red), and disclosed in
data/of/lectionary.sexp's own regenerated provenance header (tools/
bootstrap_lectionary_of.ml now runs the same parser at generation time
and names the count and the set).

Verified EF-unaffected: git diff v1.0.0..HEAD -- lib/kernel/
lib/rites/rite_ef/ data/ef/ is empty, and `colitur day`/`readings`
output for 2027 is byte-identical against the pre-fix binary.

1 files changed, 8 insertions, 1 deletions

diff --git a/lib/citation/parse.mli b/lib/citation/parse.mli
index 3d1053c..ea38d24 100644
--- a/lib/citation/parse.mli
+++ b/lib/citation/parse.mli
@@ -8,7 +8,14 @@
     ([John 18:1-40; 19:1-42]) and really does list disjoint verse ranges
     within a chapter ([Dan 13:1-9, 15-17, 19-30, 33-62]). *)
 
-type verse_range = { first : int; last : int option }
+(** A verse number, plus an optional trailing sub-verse letter run ([""] for
+    the overwhelming majority -- see parse.ml's own citation): ["11a"] is
+    [{ n = 11; suffix = "a" }], preserved through parsing and rendering
+    rather than dropped, so a reader never loses precision the source text
+    actually carried. *)
+type verse_num = { n : int; suffix : string }
+
+type verse_range = { first : verse_num; last : verse_num option }
 type part = { chapter : int; verses : verse_range list }
 type t = { book : Book.id; parts : part list }