docs: no em dashes in the docs or the report strings

[TMHSDigital]

Replaces the 34 em dashes left in tracked markdown and src/, and adds a CI job so they do not come back.

Replaced (34):

• src/plumbline/report/markdown.py: 18. All of them were the report's bullet separator, - **Label** — text, which becomes - **Label**: text. This changes report text, not any number. No test pinned the old separator.
• docs/example-report.md: 5. These are the same bullets. I changed them to match what the code now emits rather than regenerating the file, because the latency line differs on every run. The build still checks the ECE and accuracy lines against a fresh run, and it passes.
• docs/PLAN.md: 7. datasets/public/README.md: 3 (our file, not the vendored one). CHANGELOG.md: 1. Each one was rewritten with a colon, parentheses, or a comma, whichever the sentence needed.

Untouched: datasets/public/jevbench-hard.jsonl (60 em dashes in the vendored MIT rows) and LICENSE-jevbench.

CI: a new prose job in ci.yml runs git grep -P '\x{2014}' -- '*.md' 'src/' ':!datasets/public/' and fails if it finds anything. I tested it locally both ways: it passes on this tree and catches a dash I injected.

Local: ruff, format, mypy, the full pytest suite, and build_site.py all pass.

🤖 Generated with Claude Code

[TMHSDigital]

Correction to the description above: I said the example report's latency line "differs on every run". It does not. The mock simulates latency from its seed, so a rerun of the recorded command reproduces every line of the report, latency included, and the hand edits in this PR are byte-identical to what the code now prints. The site build now checks every line (only the date and path separators are normalized); see the follow-up PR.