ADR: lineage record version compatibility

[jorgee]

Summary

• Adds an ADR (adr/20260522-lineage-version-compatibility.md) describing how nf-lineage records should evolve across Nextflow releases.
• Adopts semver MAJOR.MINOR version strings (lineage/1.0, lineage/1.1, lineage/2.0, …) with a 1:1 mapping to a JSON schema document. The existing lineage/v1beta1 string is grandfathered as a legacy tier label.
• Defines a tolerant-reader contract within a MAJOR (compatible deltas: add nullable, remove unused, add new kind) and a JSON-tree migration mechanism for cross-MAJOR records.
• Documents future work: extracting a serde/migration/ package and LinMigrationRegistry when the first cross-MAJOR migrator lands, plugin-contributed migrators as an SPI, and schema-generation tooling in the nextflow-io/schemas repo.

This is a design-only change. No code is modified by this PR. The minimal LinTypeAdapterFactory read-dispatch update will land in a follow-up PR once the ADR is accepted.

Background

Today LinTypeAdapterFactory.read() rejects any record whose version does not equal LinModel.VERSION exactly. That works while only one version exists, but it is a guard, not a versioning strategy. Before any non-trivial change to the lineage model lands, we need a written contract that distinguishes compatible deltas (no migration) from incompatible ones (explicit migration), and a recipe for keeping old records readable on upgrade.

Test plan

• Review the ADR for completeness and adherence to the existing adr/ style (cf. adr/20260306-record-types.md).
• Confirm the compatibility table reflects the intended evolution rules.
• Confirm the deferred items (registry extraction, plugin migrators, schema tooling) belong as Future Work rather than this ADR's scope.

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	7abd82b
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/6a103e66fe45d00008c82174