0.27.3

A release cut later retroactively failed the gate of a release cut earlier, and 0.27.1 sat on the remote for an hour as a tag nobody could find a release for.

Fixed

• status --check and version-check asked the clone what had shipped, not the commit. 0.27.1 and 0.27.2 left in one git push. The Release workflow for 0.27.1 checked out 0.27.1's commit — with both tags fetched, because a clone holds the tag namespace and not a snapshot of it. docs/status.md at that commit recorded 38 tags; git tag answered 39; the drift check refused a release that had been correct when it was cut, and the publish step after it never ran.

  Every tag lookup in xtask now asks for the tags reachable from HEAD, so each release's gate answers the question it means to ask: what had shipped as of this commit. status, version_check and previous_tag all took the same filter. At the tip of main the two sets are identical, so nothing about the everyday check changes.

  Pinned by a test that builds the same shape — two tagged commits, HEAD detached at the older one — and which fails with the workflow's own error message when the filter is removed. The check that was supposed to catch drift could not catch its own release, which is the recurring shape of this repository's defects: the safety net needed a second one behind it.

  0.27.1's GitHub Release is now published from its CHANGELOG.md section — byte-for-byte what the workflow would have produced, since this repository's Release workflow attaches no binaries.