ci: publish test coverage badge for assert helpers

[tapheret2]

Why

bashunit ships its own coverage engine (--coverage, src/coverage.sh, docs at docs/coverage.md) with LCOV output (coverage/lcov.info), but CI never runs it and README has no coverage badge. Dogfooding the coverage feature in this repo's CI both advertises the feature and guards it against regressions.

Proposal

1. New CI job (in .github/workflows/tests.yml or a dedicated coverage.yml), Linux + recent bash only: ./bashunit --coverage --coverage-paths src/ tests/unit/ (start with unit tests; expand to functional if runtime is acceptable — measure and note in the PR). Confirm LCOV lands at coverage/lcov.info.
2. Publish a badge without adding a paid/external service dependency, using the repo's existing gh-pages deployment (.github/workflows/deploy-gh-pages.yml): extract the total-coverage percentage from the LCOV/text report, write a shields.io endpoint JSON ({"schemaVersion":1,"label":"coverage","message":"NN%","color":...}) to gh-pages, and reference it from README via https://img.shields.io/endpoint?url=.... (If maintainers prefer Codecov/Coveralls instead, swap step 2 for an upload action — decide in the PR, the CI job in step 1 is identical either way.)
3. Optionally enforce a floor later with the existing --coverage-min flag — do NOT add a threshold in this issue; just publish the number.

Acceptance criteria

• CI job runs --coverage on every push to main and produces coverage/lcov.info as an artifact.
• README shows a coverage badge that updates from main.
• Job failure does not block unrelated PR checks (run on main pushes, or as a non-required check).
• docs/coverage.md gains a short "this repo's own coverage" note linking the workflow as a real-world example.

Notes

The coverage engine itself is the most likely source of friction (it is the newest large subsystem, src/coverage.sh ~85KB). If the job surfaces bugs, file them separately and land the workflow against tests/unit/ only.