Widen the braille specs from Danish to 102 upstream specs

[henrikottesorensen]

Stacked on #15. This PR's base is that branch, so the diff and commit list below are only this change. GitHub will retarget it to main automatically when #15 merges.

Chain: #9 → #10 → #15 → #16

Runs liblouis's own expectations for roughly 60 languages through the wrapper instead of only Danish. 102 specs, all passing.

Five things the reader did not model

Every one was found by specs failing, not by reading the format:

• a test entry can lead with a description — [label, input, expected]
• a translation table can be written inline as a block scalar rather than named. nemeth.yaml failed 133 of 133 on this alone
• so can a display table, same cause
• a table can be named by file rather than by query, in which case it must not go through lou_findTable
• typeform, mode, inputPos, outputPos and cursorPos change what the expected output means, so those cases are counted and dropped rather than run against the wrong expectation

That last one is the design point. BrailleSpec.SkippedConstructs records what was recognised but not driven, so coverage that is not happening stays visible instead of quietly disappearing:

Construct	Occurrences	Maps to
inputPos	5,071	position arrays
outputPos	5,070	position arrays
typeform	522	TypeForm
cursorPos	19	cursor handling
mode	19	TranslationMode

Anything outside that list still throws. Driving these would widen the corpus and cover wrapper surface that has no tests today — the same job twice over.

Why each spec runs on its own large-stack thread

Compiling a table can recurse deeply. ancient-languages-borger.utb needs between 640 KB and 768 KB, which is more than the test host gives a test, and a stack overflow kills the process rather than failing a test.

It is compilation, not translation — once a table list is compiled, translating through it runs in 128 KB. Nothing about the input matters; ASCII overflows the same as non-BMP. And liblouis caches compiled tables process-wide, keyed by table-list string and never evicted, so without a large stack somewhere the outcome depends on which test happened to compile a given table first.

Worth knowing beyond the tests: the same failure is reachable in production. An ASP.NET request thread has about 1 MB. A service that compiles a table list for the first time on a request thread can overflow the same way, uncatchably. Compiling table lists at startup avoids it. Diagnosed jointly with the P/Invoke audit session, after we both drew wrong conclusions from experiments that were really measuring the compile cache.

40 specs held back

Not because they are wrong — because nobody has established yet whether the disagreement is the harness or the wrapper, and a suite that is expected to be red is worse than a smaller green one. Listed with reasons in braille-specs/README.md:

• 29 fail on table resolution, and are probably one root cause rather than 29: 22 report no table matching a query, 7 resolve to a table other than the one __assert-match names. The queries look well formed (language:bn grade:1), so the likely cause is which tables reach lou_indexTables or which liblouis manages to analyse. Cheapest place to start.
• 10 disagree on translation output, a fraction of cases each — no.yaml 167/868, ru.yaml 39/140. The interesting group: either an unmodelled per-case option or a real difference.
• 1 does not parse: a multi-line double-quoted scalar YamlDotNet rejects.

🤖 Generated with Claude Code

---

Recreated from #16 to move the head branch onto Notalib/LibLouis.NET, which GitHub stacked PRs require (stacks cannot span forks).