Soft-rename `protvista-uniprot` → `protvista` for the v5 release; keep the old name as a transitional alias for one major cycle

[dlrice]

Context
The package name protvista-uniprot ties the codebase to UniProt at the most visible level — every consumer's import 'protvista-uniprot' and every page's <protvista-uniprot> tag. The whole spirit of the Q1 architecture audit (#98) is decoupling the codebase from UniProt-specific assumptions; the audit identifies 14 hardcoded assumptions and removes most of them. The package name is the most visible coupling left.

The npm name protvista is currently free (verified npm view protvista returns 404 on 2026-04-29). The grant application also commits to "All modifications will maintain full backward compatibility for existing integrations," which rules out a hard rename and points squarely at a soft (aliased) rename.

Section C item C1 of docs/architecture-audit.md currently lists the tag and package name as kept-for-compatibility, with a hedge noting this rename is under consideration. If this issue lands, that hedge gets resolved; if it doesn't, C1 stays as-is.

Task
Publish protvista as the canonical npm package and a non-UniProt-coupled custom-element tag (e.g. <protvista-viewer>) for the v5 release. Keep protvista-uniprot and <protvista-uniprot> working as transitional aliases throughout the v5.x cycle so existing consumers don't break on upgrade. Remove the aliases in v6.0.0.

Scope:

• npm package. Publish protvista as a fresh package built from the same source. The existing protvista-uniprot package becomes a thin re-export of protvista for the v5.x cycle: a one-file index.js that re-exports everything from protvista, plus a package.json description field marking it as a transitional alias and pointing at protvista.
• Custom-element tag. Decide the new tag name first (suggestions: protvista-viewer, protvista-protein-viewer, protvista-protein). Register it in customElements.define alongside the existing protvista-uniprot registration. Both tags resolve to the same class. Document the new tag as canonical and the old tag as deprecated-but-supported in docs/architecture.md.
• Console-once deprecation warning. When the old tag is mounted or the old package is imported, emit a single console.warn per page-load along the lines of "<protvista-uniprot> and the protvista-uniprot npm package are deprecated and will be removed in v6.0.0; please migrate to <protvista-viewer> and the protvista npm package. See [migration guide URL]." Throttle to once per page so the warning isn't a spam vector.
• Migration guide. Add a docs/migration-v4-to-v5.md (or similar) covering: install the new package, swap the tag name, no other code changes required, deprecation timeline, FAQ. Link it from README and from the deprecation warning.
• README + docs. Update the README to lead with protvista / <protvista-viewer> and mention protvista-uniprot only in a "for v4 consumers" callout. Update docs/architecture.md's opening paragraph and any customElements.define-related sections.
• Repo rename. Optional but worth considering: rename the GitHub repo from ebi-webcomponents/protvista-uniprot to ebi-webcomponents/protvista. GitHub redirects the old URL automatically. Worth doing in the same change so the rename is unambiguous; existing comment / blog / paper links continue to work.
• Audit doc. Update section C item C1 of docs/architecture-audit.md to reflect the decision: the tag and package are no longer "kept for compatibility forever" — they're "preserved as transitional aliases through v5.x, removed in v6.0.0".

Notes:
The grant application's backward-compatibility clause is what rules out a hard rename; this issue specifically picks the soft path so existing v4 integrations keep working through v5.x. The deprecation warning is the load-bearing piece — without it, consumers don't notice the rename is happening and get caught out at v6.

Open design questions to resolve when picking this up:

1. New tag name. protvista-viewer is the most descriptive; protvista-protein-viewer is more anchored to the domain; protvista-protein is shortest but reads weirdly. The decision affects every consumer's HTML, so worth a short office-hours conversation with known integrators (UniProt website, Open Targets) before committing.
2. Repo rename timing. Either as part of this issue or as a separate visible step. If separate, sequence repo rename after the npm rename has stabilised on a few releases so external links don't break twice.
3. protvista-uniprot shim depth. Two flavours: (a) full re-export with deprecation warning, or (b) package.json "deprecated": "..." only and tell consumers to install protvista directly. Flavour (a) is more consumer-friendly; flavour (b) is more decisive about driving migration. Pick (a) for the grant period to honour the backward-compat commitment; revisit before v6 if uptake of the new name is strong.
4. AlphaFold default config. The bundled default-config.yaml is named for UniProt content — it stays UniProt-specific because that's the canonical reference. The package being called protvista doesn't change what the default config contains; it just stops implying that the package is UniProt-only.

Acceptance: a fresh consumer running yarn add protvista and using <protvista-viewer accession="P05067"> gets a working viewer; an existing v4 consumer running yarn upgrade protvista-uniprot to v5.x keeps working without code changes; both paths emit the right console messages (none for the new path, one deprecation warning per page-load for the old path); the migration guide answers the obvious questions; section C of the audit doc reflects the resolved decision.