Keep several versions of one story in the library, with history #16

Contexte

Origin: the wish to make a series of versions of the same story and keep the history. A device session (see FORMATS.md §9, PR antoinevalentinHA#59) established what the formats offer, and it is little:

• The story pack version (u16 at ni offset 2, "version" in story.json) travels through every format, the editor edits it, the library names archives <title>-<uuid>-v<version>.zip, the device stores it. Nothing is known to read it.
• The device identifies a story by UUID only (.pi entry, .content/<tail of uuid>). Same UUID → the upload replaces. Different UUID → a second, unrelated story.
• The pack UUID is the first stage node's UUID. The editor keeps node UUIDs across load/save, so editing and re-exporting keeps the identity. Re-creating the story, or duplicating its first node, gives it a new one.

The card checked had the same STUdio story under two UUIDs with byte-identical ni, plus its current v2 under a third. That is the failure mode: versions made by re-creation pile up on the device as siblings it cannot relate, and only the library file names remember which is which.

Description

Make the library the place where history lives, keyed by UUID, so the device holds one version per story and the user can go back.

Design decision to settle first (the rest follows from it):

• A. Same UUID, incrementing version (recommended). The library keeps all archives of one UUID; the tile shows the versions; the highest (or the selected one) is what goes to the device; uploading replaces the previous one on the device. History is a library concept, the device never sees two copies.
• B. One UUID per version. Versions coexist on the device, but the device cannot relate them, the user has to remove old ones by hand, and the library cannot tell "v2 of X" from "another story" without a side table. This is what happens today by accident.

Fichiers concernes

• web-ui/src/main/java/studio/webui/service/LibraryService.java — packs are already grouped by UUID (packs[0]); today the group is "formats of one pack", it would become "versions × formats"
• web-ui/javascript/src/utils/packs.js (sortPacks, chooseDropAction) and PackLibrary.js — pick which version is sent on drop; show versions on the tile
• web-ui/javascript/src/components/diagram/widgets/PackDiagramWidget.js — the version input exists; consider bumping on "save as new version"
• web-ui/javascript/src/utils/packs.test.js, LibraryService tests — selection rules

Plan d'implementation

1. Decide A vs B (above).
2. Library model: a pack group = one UUID → list of (version, format, path); define "current" = highest version.
3. UI: versions visible on the library tile; drop-to-device sends the current one; a way to pick an older one.
4. Editor: "save as new version" = same UUID, version + 1, new archive; never regenerates node UUIDs.
5. Guard: uploading a lower version than the one on the device asks for confirmation.
6. Tests for grouping, current-version selection and the guard.

Criteres d'acceptation

• Several archives of the same UUID coexist in the library and are shown as versions of one story
• Dropping the story on the device sends exactly one version, the current one by default
• Re-exporting from the editor never changes the story's UUID
• yarn test and the Java suite green, CI green on Ubuntu and Windows

Complexite

M