fix: floor the version graph at 33.0.5:0

[MattDHill]

What is wrong

canMigrateFrom is >=32.0.11:0 && <=34.0.4:5, which claims an install on Nextcloud 32 can migrate into a package bundling Nextcloud 34. It cannot: Nextcloud upgrades one major at a time, and guardUpstreamUpgrade refuses the jump during init. The prod registry publishes exactly that range as 34.0.4:4's sourceVersion today, so a 32 install is offered 34 and rolled back.

The 0.3.5.x registry now serves Nextcloud 33.0.8 as current, so most carry-overs land on 33.0.8:0; a server that never updated there still carries over on 32.0.11 or older.

The change

The floor of a version graph is the lowest declared version whose up is IMPOSSIBLE. Replacing the 32.0.11:0 anchor with one at 33.0.5:0 (the oldest published 33 revision) moves it. Ships in 34.0.4:5 — no version bump.

Executing the real graph:

canMigrateFrom: >=33.0.5:0 && <=34.0.4:5
32.0.11:0  false
33.0.5:0   true
33.0.7:0   true
33.0.8:0   true
33.0.8:3   true
34.0.3:6   true
34.0.4:4   true

The 0.3.5.x layout migration is unaffected. dump() shows the >=33.0.5:0 && <33.0.8:2 range vertex still carries clearTask + migrateFrom035x into 33.0.8:2, so a 33.0.8:0 carry-over runs it on the way to 34.0.4:5.

guardUpstreamUpgrade reads its data-version floor from priorVersions, which now starts at 33. For a Nextcloud 32 install that lookup finds nothing and the guard only throws its "update to a release bundling Nextcloud 33 first" error — the only path an install outside the graph can reach.

With Start9Labs/start-technologies#3807 deployed, the registry routes a 32.0.11:0 install to a 33 release instead of this one.

Verified

• Rebased onto master (34.0.4:5); npm run check and Prettier green.
• Range and per-version satisfaction executed against the installed SDK (2.0.9), output above; versionGraph.dump() inspected for the migration path.
• Not installed on a box.