fix(provenance): anchor with \Z, so a trailing newline is not part of an identifier

[lywinged]

Follows the anchoring point from my review comment on #146, which nobody has picked up. Two lines of pattern and one parametrized test.

What it is. In Python $ matches at the end of the string and immediately before a single trailing newline. Both patterns in this module are anchored ^...$, so every field they guard accepts its own value with a newline glued to the end, and verify_record returns cleanly.

Two patterns, four fields:

publisher             "did:web:acme.example\n"   accepted
artifact.digest       "sha256:...\n"             accepted
endpoint.spki_sha256  "sha256:...\n"             accepted
tool_catalog.hash     "sha256:...\n"             accepted by verify_record

Only the last has anything downstream to catch it, and only because check_tool_catalog recomputes the digest and compares. The other three are accepted and nothing later disagrees.

\Z is the end of the string and nothing else. One comment sits on the pair, because the two anchors look interchangeable and are not.

Correcting my own report. On #146 I said this affected two fields and that "the hash case fails safe". Both halves were too narrow. It is four fields, because the two patterns are reused, and fails safe is true of tool_catalog.hash and false of artifact.digest, which is the same digest pattern with no recomputation behind it. I had checked one field and described the pattern.

Verified. Four parametrized cases, one per field. They fail on all four before the change and pass after; I ran it both ways rather than assuming. 327 passed, 1 skipped. ruff and mypy clean.

Not in this PR: the regexes are permissive in other ways. did:[a-z0-9]+:.+ accepts a DID with a space in it, and .+ accepts a great deal. That is a separate question from anchoring and I have not touched it.

[github-actions]

❔ Contributor Check: UNKNOWN

Check	Result
Profile	UNKNOWN
Credential	LOW
Overall	UNKNOWN

Automated check by AgenTrust Contributor Check.

[imran-siddique]

Confirmed the behaviour directly rather than from the description: re.match(r'^sha256:[0-9a-f]{4}$', 'sha256:abcd\n') matches, and the same pattern with \Z does not. So all four fields guarded by these two patterns accepted a trailing newline, and verify_record returned cleanly on three of them with nothing downstream to disagree.

The parametrized test is the right shape here: the bug is one property of two shared patterns, and covering all four fields means a future field added to either pattern inherits the guard instead of quietly re-opening it.

Merging this first. #149 now carries the same two lines after your rebase, so I will rebase it down to just the thumbprint comparison.