feat(publication): GS1 Digital Link qualifiers and GTIN history - #684

… out of shared caches

`Publisher::redactAll()` redacted only the `is_current` versions before
flipping the publication to Redacted. Every superseded version kept its
sealed payload readable in the database, so a GDPR Art. 17 erasure held
only for as long as nothing ever read history. Now every not-yet-redacted
version of the publication is redacted; versions already redacted on
their own are left untouched.

The public tombstone changes with it. A redacted passport answers
`410 Gone` (the state is irreversible), while a withdrawn one stays `200`
because it can be reinstated. Both tombstones are now `private, no-store`
and `noindex`: the package has no cache purge hook, so a shared cache
must never hold a tombstone that a reinstatement would have to displace,
and the tombstone must not be indexed regardless of the channel's
`indexable` setting.

Tests: redactAll nulls superseded payloads and stamps the reason on
them; a version redacted individually earlier keeps its own reason; the
redacted route is 410 + no-store + noindex; the withdrawn route is 200 +
no-store + noindex.

Adds `GET /{prefix}/{uuid}/r/{sequence}/{locale}`: the state of the
passport as of one release, for one locale, resolved through
`PublicationRelease::versionsAsOf()`. This is the URL a printed carrier
can be bound to: it names one moment across every language and keeps
resolving to exactly that state after the passport moves on.

Semantics:
- strict locale, no Accept-Language negotiation; a locale that had no
  version yet at that release is 404 there
- 200 with a banner naming the release and whether it is still current,
  linking to the live page; the locale switcher stays inside the release
- never indexed (`noindex, noarchive, nofollow`, a `<link rel=canonical>`
  and a `Link` header pointing at the live page); no JSON-LD negotiation,
  since a historical payload's stamped identity is the publication URL
- a version redacted individually renders the tombstone with 410 and
  `no-store`, even while the publication itself stays Published; this
  also closes the same gap on the live route
- the ETag now covers release, currency and redaction state, because
  the banner and the tombstone change the HTML without changing the
  checksum; TEMPLATE_VERSION bumped
- release pages are not counted as views

`show()` and `showRelease()` share one `render()`. The four new strings
live in the Publication package and are present in all 33 locales, in
English where no translation exists yet, so the translation audit passes.

A scanned GS1 link can carry the lot (AI 10) and serial (AI 21) that tie
a unit to the release it was placed on the market under. Add
`/01/{gtin}/10/{lot}`, `/01/{gtin}/21/{serial}` and the combination,
validated against the GS1 82-character set and 1-20 length in the
controller (a malformed qualifier is a bad link: 404, never a guess).

Which release a lot shipped under is not the PIM's knowledge, so the
mapping sits behind a `LotReleaseResolver` contract. The default binding
answers null and a qualified scan then resolves exactly like an
unqualified one, to the live passport. A consumer with batch or ERP
data rebinds it; when it names a release, the scan 302s to that
release's strict per-locale URL, with the locale negotiated once.

`publications.gtin` was overwritten on every publish, so a corrected
GTIN silently broke every `/01/{old}` link already printed. Add
`publication_gtins`, an append-only history written by
`SyncPublicationGtin` and backfilled from current values;
`PublicationResolver::findByGtin()` falls back to it when no publication
carries the scanned GTIN today, with the same designated-channel rule.

The project keeps method and test bodies comment-free. Move the rationale
added with the GS1 qualifiers into the PHPDoc of the method or class it
explains (service provider register() and registerPublicRoutes(),
SyncPublicationGtin, PublicationResolver::findByGtin()). In the qualifier
test, the unknown-lot case becomes its own it() so its name carries the
intent.

When more than one publication has carried the same GTIN (it moved from A
to B, then was corrected away from B too), the history fallback in
findByGtin() ended in first() without an ORDER BY when a passport channel
was configured, or in a channel_id tie otherwise, so the result depended
on the database engine.

Order the history by recorded_at desc, id desc and pick the first
candidate that passes the channel rule in PHP. The designated passport
channel still restricts the candidates, and the warning for the
undesignated case is kept. A data-provider test covers a later carrier on
the higher channel, on the lower channel, and an identical instant.

The GTIN history is append-only, so a GTIN published by mistake (a typo
that belongs to another brand, say) kept resolving to the passport that
once carried it. Add a nullable revoked_at to publication_gtins that the
history fallback skips, keeping the table append-only: PublicationGtin
now permits exactly one change, setting revoked_at on a row that is not
revoked yet, via revoke().

`unopim:publication:revoke-gtin {gtin} {--publication=}` retires the
active history entries for a GTIN. It refuses a malformed GTIN and leaves
alone a publication that still carries the GTIN today, since correcting
that is a republish. Revoking never touches publications.gtin, so a
publication that publishes the GTIN again resolves through its current
value as before.

The column joins the create migration of the same pull request, which has
not shipped yet.

SyncPublicationGtin ran an update and an insertOrIgnore on every publish.
Both only matter when the GTIN differs from the one the publication
already carries, so skip them when it does not. The canonical alias
handling still runs.

…'s release

A LotReleaseResolver that names a release of a different publication is a
bug in the consumer's resolver. The controller already refuses to follow
it and falls back to live, but did so silently. Log a warning with the
resolver class, the publication and the release so the bug is visible.

Also document in the PHPDoc that a lot or serial containing `/` does not
resolve: it is valid in the GS1 82-character set, but the router matches
the decoded path, so a `%2F` splits the segment and the link 404s.

…nd encoded slashes

Pin the three small behaviours of the qualifier routes and the GTIN sync:
a publish with an unchanged GTIN performs no history or GTIN write, a
resolver returning another publication's release logs a warning and lands
on live, and a serial with an encoded slash 404s (a documented limitation
of the route grammar).