fix: floor the version graph at 33.0.5:0

[MattDHill]

Warning

Do not merge or release before Start9Labs/start-technologies#3807 is deployed to the registries. On its own this change makes the failure it describes worse, not better. See "Sequencing" below.

Stacked on #131 — the floor only makes sense once current is 34.0.3:0.

What is wrong

canMigrateFrom is >=32.0.11:0 && <=34.0.3:0, which claims an install on Nextcloud 32 can migrate into a package bundling Nextcloud 34. It cannot. $OC_VersionCanBeUpgradedFrom in v34.0.3/version.php is {33.0, 34.0}, and startos/init/bootstrapNextcloud.ts:165 refuses the jump during init.

32.0.11:0 is the version a StartOS 0.3.5.x carry-over lands on — the legacy registry serves Nextcloud 32.0.11 as current, and emver 32.0.11 → exver 32.0.11:0. So this is not a theoretical cohort.

The change

The floor of a version graph is the lowest declared version whose up is IMPOSSIBLE — everything below it has no edge into the graph, so the reverse search stops there. Replacing the 32.0.11:0 anchor with one at 33.0.5:0 (the oldest published 33 revision, v33.0.5_0) moves it.

Executing the real graph:

canMigrateFrom: >=33.0.5:0 && <=34.0.3:0
  32.0.11:0   -> false
  33.0.5:0    -> true
  33.0.6:2    -> true
  33.0.7:0    -> true
  33.0.8:0    -> true
  33.0.8:1    -> true
  33.0.8:2    -> true
  33.0.8:3    -> true

The 0.3.5.x layout migration is unaffected. dump() confirms the synthesized range vertex still carries it:

{
  "metadata": ">=33.0.5:0 && <33.0.8:2",
  "edges": [{ "metadata": "clearTask(...); migrateFrom035x(...)", "to": "33.0.8:2" }]
}

so every 33.x revision below :2 still runs clearTask + migrateFrom035x on the way to 34.0.3:0.

Why the 32.0.11:0 anchor is dropped rather than kept alongside. With a higher IMPOSSIBLE floor above it, it contributes no edges and sits in no path the reverse search can reach — the range is identical with or without it. Per the packaging guide, a version having been released is not on its own a reason to declare it.

Note that simply removing v_32_0_11_0 without adding a replacement does the opposite of what's wanted: the graph then synthesizes an unbounded <33.0.8:2 vertex and the range widens to <=34.0.3:0.

Sequencing

This change alone does not stop the Updates tab offering 34.0.3:0 to a 32.0.11:0 install. The Updates tab filters on installed / newer / flavor only (filter-updates.pipe.ts); the piece that would consult canMigrateFrom is updates-refinement.service.ts, and it is dead because the registry never publishes the field — source_version: None, // TODO in registry/package/index.rs, which is what #3807 fixes.

So until #3807 is deployed, the sole effect here is to change how the update fails for that cohort:

	offered?	failure
today (>=32.0.11:0)	yes	init guard: "Cannot update Nextcloud from major version 32 directly to 34… pick a 33 release from the version list", then rollback
this PR, #3807 not deployed	yes	service_map.rs computes target_range(prev_can_migrate_to ∧ next_can_migrate_from), which is unsatisfiable → uninit target range … is unsatisfiable — no version can satisfy it (host contract violation), then rollback
this PR, #3807 deployed	no — 33.0.8:3 offered instead	none; the two-step update just works

Same rollback and the same safe data in all three, but the middle row replaces a message naming the remedy with a host-contract error. That is why #131 ships first with the permissive floor, the actionable guard message, and the release-note bullet pointing at the version picker — those are the interim mitigation — and this lands only once the registry can route around it.

Verified

• npm run check and npx prettier --check green.
• Range and per-version satisfaction executed against the installed SDK (2.0.9), output above.
• versionGraph.dump() inspected for the migration path.
• Not built, not packed, not installed.