feat(ci): publish an instrumented coverage badge

[kikoso]

Closes #241 (open since December 2022).

Why this is small now

#1000 already does the hard part: coverage-history.yml records a TOTAL row per suite into history.csv on the coverage-history branch after every merge to main. The badge just has to expose a number that is already being collected.

Which number, and why

The badge reports the instrumentation suite, not unit. Current totals:

suite	line	branch	instruction
instrumentation	20.87%	17.78%	23.83%
unit	0.42%	0.09%	0.21%

This library is a Compose wrapper around a MapView, so JVM unit tests structurally cannot cover much of it (11 covered lines out of 2,639). A badge wired to the default suite would put "coverage 0%" on the front page and would be actively misleading about how tested this library is.

The label reads coverage (instrumented) rather than plain coverage, so the figure is not mistaken for a whole-project number, and the badge links to COVERAGE.md on the data branch where both suites are broken out per module.

Happy to switch to two badges (unit alongside instrumented) if you would rather show both.

Changes

• coverage_history.py: new badge subcommand emitting shields.io endpoint JSON from the latest TOTAL row. Standard library only, consistent with the rest of the script. A suite with no recorded entry renders as a grey "unknown" rather than failing, so the badge degrades quietly instead of breaking the README.
• coverage-history.yml: regenerate the badge alongside COVERAGE.md in both record steps, so the file exists even before the first instrumentation entry lands and refreshes as soon as one does.
• README.md: one endpoint badge, next to the existing Tests/Build badge.

Two bugs found in push_coverage_history.sh while testing

Worth calling out, because without these the feature would have silently done nothing:

1. It hard-coded history.csv COVERAGE.md in both its change detection and its git add, so the badge file would have been generated and then never committed.
2. It checked for changes with git diff before staging. git diff does not see untracked files, so on the badge's very first run the guard would have reported "unchanged" and exited before committing it. Now it stages first and compares the index.

Both paths (initial push and the push-rejected retry) are fixed, and the file list is a single FILES array so the next added output does not repeat this.

Verification

• badge exercised against the real history.csv from the data branch: renders 21% / orange.
• Degradation paths checked: empty CSV and missing CSV both produce unknown / lightgrey.
• The push logic was run end to end against a real clone of coverage-history, confirming it now stages and would commit the new file (it reported "would SKIP commit" before the fix).

Sequencing note

coverage-badge.json does not exist on the data branch yet, so until the first post-merge run of "Record coverage history" the shields endpoint returns custom badge: resource not found. The workflow already has workflow_dispatch, so triggering it once right after merge populates the file immediately and avoids that window.

[github-actions]

Coverage (unit tests)

No unit baseline recorded in coverage/history.csv yet, so this run only reports absolute numbers.

Module	Line %	Change	Branch %	Change
maps-compose	0.00%	new	0.00%	new
maps-compose-utils	2.04%	new	0.49%	new
maps-compose-widgets	0.00%	new	0.00%	new
TOTAL	0.42%	new	0.09%	new

_{Line and branch coverage from unit test reports. History is recorded in coverage/history.csv after each merge to main.}

[googlemaps-bot]

Code Coverage

Overall Project	24.59%	❌

There is no coverage information present for the Files changed