Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

The matrix marked every accepted pair with a plain tick, which reads as
"everything works". It does not. ProtocolVersion bumps PATCH for sub-channels a
peer can safely ignore, so Paper 1.3.0 (protocol 1.0.1) against Velocity 1.1.0
(1.0.0) completes the handshake and then silently drops cross-server direct
messages — the very feature that PATCH was bumped for. An operator reading the
tick had no way to learn that, and the pages around it repeated the claim.

The handshake is settled by MAJOR and MINOR alone, so any difference left once a
pair is accepted is a feature the newer end offers and the older will never
answer. Those pairs now carry a warning that says which end lags. Naming the
feature would take a protocol-version-to-feature table on the website, which
would drift from the protocol it describes, so the warning stays general and
leaves the reader one hop from the compatibility page.

The handshake verdict keeps the three checks that mirror Velocity's gate, with
the new one layered after them, so the mirror stays honest. isCompatible now
holds for a degraded pair, which does connect.

Cells are built once per pair in a computed instead of recomputing on each of the
template's reads, which a third state would otherwise have multiplied.

Co-Authored-By: Claude <noreply@anthropic.com>

Biome 2.5.7 deprecates `linter.rules.recommended` in favour of `preset` and will
drop it in the next major, so the config emitted a deprecation notice on every
run. Renaming it now keeps `bun run lint` and `format:check` clean and spares a
forced edit at the next upgrade; the rule set it selects is unchanged.

Co-Authored-By: Claude <noreply@anthropic.com>

`includes` stopped at `.vitepress/theme/*.ts`, so everything under
`components/` went unchecked — including the release and compatibility logic
this branch touches. Widening it to `**/*.ts` takes the check from five files to
nine.

`.vue` stays out. Biome does not resolve `<script setup>` bindings used from the
template, so it reports the components' `t`, `data`, `loading` and formatters as
unused and offers to delete them; admitting those files would mean turning off
noUnusedVariables and noUnusedImports to buy nothing.

Co-Authored-By: Claude <noreply@anthropic.com>

The badge read `v1.3.0~`, pointing at a Velocity release that does not exist.
The feature needs both halves, and the Velocity half first shipped as 1.2.0
inside the unified v1.3.0 release, so a reader hunting for Velocity v1.3.0 finds
nothing and cannot tell which proxy build carries the relay.

Also refreshes the gradle.properties example, which still showed the versions
current when it was written.

Co-Authored-By: Claude <noreply@anthropic.com>

The download cards and the compatibility matrix derived each plugin's version
from the release tag, which cannot hold for a unified `vX.Y.Z` release: it
carries both JARs and their versions need not agree. v1.3.0 shipped Paper 1.3.0
alongside Velocity 1.2.0.

So the download page advertised Paper v1.2.2 and Velocity v1.1.0, two
generations stale, because it searched `paper/v` and `velocity/v` tags first and
fell back to a unified tag only when none existed. The matrix meanwhile put a
Velocity v1.3.0 on its axis that was never released, leaving no row for the
proxy build operators actually run.

Both now pick releases by the JARs attached to them and take the version from
the file name, the only place it is stated. Tag shape stops mattering: a
platform-specific tag and a unified one are alike just releases that happen to
carry a given JAR.

Releases rank by publication time rather than by API response order, which
follows tag creation instead: velocity/v1.1.0 precedes the later-published
paper/v1.2.2.

A version is listed once even when a later unified release re-attaches an
unchanged JAR, which release.yaml does whenever only the other platform was
bumped. Otherwise the matrix would carry one version twice, under two protocol
versions if the protocol had moved in between.

Tests run in CI from here on. They need an explicit path because Bun does not
discover tests inside dot-directories.

Co-Authored-By: Claude <noreply@anthropic.com>

The links were written before the English pages existed, so GitHub and Modrinth
sent an international audience to Japanese notes. Both now point at the English
pages; the Japanese ones remain reachable from the site's own locale switch.

Also stops the changelog template from being served. It lives under `src/`, so
VitePress published it as a page of empty headings at /assets/changelog-default,
where it was reachable and indexable. `srcExclude` keeps it a template.

The tag table on the changelog overview claimed `vX.Y.Z` was last used for
v1.0.0 and retired, which contradicts release.yaml and the release skill still
supporting it; it now says what the tag is for.

Co-Authored-By: Claude <noreply@anthropic.com>

The `@<server>` argument resolves against the server names registered in
`velocity.toml`, not the `features.velocityIntegration.serverName` of the
destination: PresenceTracker publishes `serverInfo.name` and
CrossServerDirectMessageRelay matches the target against the same, so the
previous text had it exactly backwards. Following it on a proxy where the two
names differ produces SERVER_NOT_FOUND every time, and points the reader at the
wrong file to fix. `serverName` still matters, for `{server}` and for
recognising local players, so what it does is stated instead.

Also corrects two claims made while widening these pages:

- `/lcv status` reports only this server's protocol version, not both sides'.
  The Velocity bug template leaned on it as its most important field, so a
  reporter would have pasted output that cannot answer the compatibility
  question. It now also says to run it after a player has joined, since the
  handshake waits for one - the same caveat the README install steps needed.
- Spies see pre-conversion text for direct messages only. Channel messages are
  converted before the handler runs, so spies get the same formatted string the
  members do.

Co-Authored-By: Claude <noreply@anthropic.com>

Release notes were written into the GitHub release body, which means they exist
once, in English only, and are awkward to revise after publishing. Putting them
on the site gives each release a Japanese and an English page that can be
corrected later and linked from anywhere.

The overview page states the versioning rules the version numbers alone do not
convey: that dropping a supported platform is a MINOR bump, that the Paper and
Velocity builds advance separately, and that the plugin version says nothing
about compatibility.

Co-Authored-By: Claude <noreply@anthropic.com>

Several statements were wrong rather than merely thin, and each would have set
the wrong expectation:

- the conversion example implied romaji replaces the input, when the result is
  appended in parentheses and both are sent
- the handshake was described as happening at startup, when it waits for the
  first player to join, so a DISCONNECTED status on an empty server read as a
  fault
- cache eviction was called oldest-first, which the unordered in-memory map
  cannot provide
- the Velocity settings table omitted crossServerDirectMessage
- ConfigManager was described as reading Bukkit's FileConfiguration, and the
  settings storage as recovering from a backup that does not exist

It also documents behaviour that had no mention anywhere: the `!` force-global
prefix, that spy sees channel messages and not only DMs, the nightly build
warnings, the overall 1000ms conversion budget that makes api.timeout above it
ineffective, and the data files the plugin writes.

Co-Authored-By: Claude <noreply@anthropic.com>