Update wisp to v0.5.14 (bounded query scan)

[helix-nine]

Rebase of #11 onto current master, plus a fix for the version-graph defect that blocks rollback of a failed update. Commits are @kwsantiago's, unchanged in substance — #11 could not be updated in place because its head lives on an organization-owned fork, where GitHub does not honor "allow edits by maintainers".

wisp v0.5.14

Queries are now bounded in how many stored entries they may scan, so a selective filter matching fewer events than its limit no longer walks the entire database. Fixes severe CPU and major page-fault load on large databases. The new query_scan_multiplier setting (default 20, 0 disables) controls the bound. (privkeyio/wisp#160)

• Dockerfile: WISP_VERSION v0.5.13 → v0.5.14, WISP_COMMIT → 40ec89eb5439c80a3b3508b5f52fcfd64d76cc9f (verified: the commit tag v0.5.14 points to)
• current.ts: 0.5.13:3 → 0.5.14:0 + release notes in all five locales

Rollback fix

migrations.down was IMPOSSIBLE. StartOS stamps the data version before an update completes, so a failed or cancelled update left the data at the new version with no path back — the automatic rollback then failed and the service could not load at all:

Update rollback failed for wisp, restoring volume snapshot:
  Error: cannot migrate from 0.5.14:0 to 0.5.13:1

An interrupted sideload wedged the service in practice until it was reinstalled. There is no data-format change between these versions, so a downgrade is trivially possible; declaring it impossible was both inaccurate and what blocked recovery. down is now a no-op.

versions/index.ts keeps other: []. #11's description proposed adding a v0_5_13.ts node and populating other, but that was never in its diff and is not needed: VersionGraph synthesizes a range vertex beneath current, so every installed version below 0.5.14:0 already migrates up in one hop, and canMigrateFrom is derived from the graph rather than fed by other.

Rebase notes

• Conflict was confined to startos/versions/current.ts — master had advanced to 0.5.13:3 (start-sdk 2.0.9). Resolved in favor of 0.5.14:0; the sdk bump itself is untouched and carries forward.
• French release-note string reformatted by prettier (double quotes, since it contains apostrophes).

npm run check and prettier --check startos both pass.

Test plan

1. Install the built s9pk on a StartOS server (fresh install, or update from 0.5.13:x).
2. Start the service and confirm the websocket interface comes up healthy.
3. Connect a Nostr client to the relay; publish an event and read it back with a filter, confirming normal relay operation.
4. Run the Limits action and confirm query_scan_multiplier behaves as configured (default 20; set 0 to disable the bound).
5. On a relay with a large event database, issue a selective filter whose match count is well under its limit and confirm CPU no longer spikes the way it did on 0.5.13.
6. Rollback check: begin an update and cancel/interrupt it, then confirm the service reverts to the prior version and loads normally rather than wedging with cannot migrate from ….