Rename the OpenPlural format to PluralPort

[SiteRelEnby]

The interchange format Sheaf co-designed was renamed upstream after a name conflict. The spec version string is unchanged at 0.1, so this is branding plus one new envelope key, not a format revision. The spec now lives at PluralPort/spec.

What changes on the wire

Exports stamp pluralport_version: "0.1" and download as .pluralport.zip carrying pluralport.json. The API's values become format=pluralport and source=pluralport_file, and the preview endpoint is /v1/import/pluralport/preview. Internally the services, schemas, tests, docs and web modules all follow the name.

Nothing existing breaks

The spec's v0.1 versioning rule requires importers to keep accepting the deprecated openplural_version key with identical semantics, and requires pluralport_version to win when a file carries both. That last part is the easy thing to get backwards, so it is pinned by a test in both directions: a file with a bogus pluralport_version and a valid openplural_version is rejected, not quietly imported under the alias.

Beyond the envelope key, every other old spelling is still accepted as a deprecated alias: the legacy openplural.json bundle member, format=openplural, source=openplural_file, the old preview route (still working, but include_in_schema=False so the generated schema stays pluralport-only), .openplural.zip in the web file picker so exports already sitting on disk still select, and the OPENPLURAL_MAX_PRESERVED_MB env var for selfhosters (the new PLURALPORT_MAX_PRESERVED_MB wins if both are set).

The one name that does not move

systems.openplural_archive, its model attribute, and system_openplural_archive_aad keep their pre-rename spelling. That string is the AAD bound into every encrypted residual-archive blob, so renaming it would make existing stored data undecryptable. All 24 sites that reference it now carry a comment saying why, because a partially-renamed file reading an openplural-named attribute is exactly where someone would later "finish the job". The exported JSON key does move to pluralport_archive, and the native importer accepts both spellings with the new one winning.

Migration and deploy note

The migration is data-only: it relabels import_jobs.source and export_jobs.format. Both are String(32) rather than Postgres enums, so there is no type surgery and no lock-taking DDL. Downgrade is symmetric.

Worth picking a quiet moment for the deploy: during a rolling restart there is a narrow window where an old instance sees a relabelled row. Harmless for the historical completed rows, but an import job sitting pending at that exact moment with the old source value would fail and need re-running.

Verification

Ruff, tsc, eslint and the web build are clean. The legacy env var alias, the query-param alias normalisation (?format=openplural returns 200 while a bogus value still 422s), and the generated OpenAPI enums were each checked directly rather than assumed. Stackless parity and unit tests pass; the full behavioural suite on the selfhosted/none config is 2051 passed / 155 skipped, which includes bringing up a stack and running the new migration.

New tests cover each compatibility path individually: legacy envelope key, both-keys precedence in either direction, legacy bundle member, legacy source and format values, the legacy preview route, the legacy archive key, and the old env var.

Not in scope

Historical alembic migrations and historical changelog entries keep their original wording, as does the record of upstream issues filed under the old name.