test(ci): make lint-readme-parity bidirectional (catch stale README rows)

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

The lint-readme-parity CI job (added for #185, closing the roadmap epic #181) verifies README ↔ action.yaml parity in one direction only: it fails if a declared input/output is missing from the README's ## Inputs / ## Outputs table.

It does not check the reverse — a README table row naming an input/output that no longer exists in action.yaml. That is precisely the drift a rename or removal leaves behind: you rename/drop an input in action.yaml, the forward check still passes (nothing newly undocumented), and the README keeps a now-phantom row that silently misleads consumers.

This repo has a history of exactly those changes — require-checks → aggregate-job-checks (v3), setup-copilot-skills → setup-agent-skills (v5), and the Codecov input/secret removal (v5) — so a stale-row guard is warranted, not speculative. Epic #181's stated goal was a library that is "mechanically inspectable for correctness, not just by social convention"; the forward-only check half-delivers that for READMEs.

Proposed direction

Make the existing lint-readme-parity job bidirectional:

• forward (unchanged) — every declared input/output must be documented;
• reverse (new) — every name in the README's ## Inputs / ## Outputs table first column must be a declared input/output in action.yaml.

Pure CI hardening — no new dependencies (yq is already preinstalled on the runner), no change to any action. The current tree passes the reverse check clean (verified locally), so it lands green and only guards future drift.

Acceptance criteria

• The lint-readme-parity job fails when a README documents an input/output not declared in its action.yaml.
• The forward direction is preserved unchanged.
• The job passes on the current tree.
• No false positives on prose code-spans (only the table's first column is read).

Size

XS — one run: block in .github/workflows/ci.yaml.