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).

[nanchen2483]

• P2 — Skipped spec coverage is not reported. The reader records unsupported constructs in BrailleSpec.SkippedConstructs, but BrailleSpecTests.cs runs only spec.Cases and never surfaces that tally. Consequently, the test output does not indicate how many cases were omitted for options such as typeform, mode, or cursorPos. Please report the skipped counts (or assert expected counts) so omissions remain visible as the PR intends.

🤖 AI-assisted review: This PR has been reviewed with AI assistance.

[henrikottesorensen]

Fixed in de2da03.

• Each spec's test writes <spec>: N cases checked, M entries skipped (construct: count, ...) to the test output and includes the same in its failure message.
• Passing-test output is easy to miss, so SkippedEntriesMatchTheRecordedTally also pins the totals across all specs: currently typeform 391, outputPos 5067, testmode hyphenate 1198, mode 14, testmode display 5. Any coverage gained or lost fails that test with the new tally.

The tally now counts dropped entries rather than constructs. Before, a flags-level testmode counted once per block, and an entry with two unsupported options counted twice. Fixing that also exposed a bug: {typeform: ..., testmode: forward} let the later testmode undo the skip, so the case ran without its typeform. An unsupported option now always drops its entry.

[henrikottesorensen]

Correction to my reply above: de2da03 was pushed to the wrong repository and never reached this PR. The fix is now here as 3b89c7d.

The recorded totals have also changed since that reply. main moved to liblouis 3.38.0, so ac4b889 re-copies the specs from 3.38.0. That release adds a new expected_typeform option (17 entries skipped), drops th-g1.yaml, and changes en-ueb.yaml in a way YamlDotNet can't parse, so that spec moves to the README's "do not parse" group. The typeform count goes from 391 to 287, mostly because en-ueb's 107 entries are gone. The commit message has the details.