fix(scaleway): a disk in the block product is reachable from its server, a DEV1-S root lives there like the cloud's, and the detach that answered 200 released nothing (#571, #365)

[stephrobert]

Closes #571. Closes #365.

A client writing root_volume { volume_type = "sbs_volume" } got a disk the
instance API could not reach. The premise held — and it was larger than five
operations, and wrong about two of them.

The table, with scw 2.56.3 against a real emulator

Each row is a fresh subject. The witness — scw block volume get on a disk that
is in block — answered on every run, so a 404 here means unreachable, never
the client is broken.

operation	before	after step 1	after step 2
block volume get <default DEV1-S root> — #365	404	404	200
attach-volume a free block volume	404	200	200
attach-volume another server's block root	404 (unreachable, not guarded)	412, the guard bites	412
server update volumes.0.id=<block root>	"does not exist"	"is attached to server X"	same
POST /instance/v1/…/snapshots (Terraform's path)	404	201	201
instance snapshot create … unified=true	rc=1	rc=0	rc=0
instance volume delete <block root>	404	404 — deliberate	404
instance server detach-volume <block root>	200, released nothing	200, released	same
server terminate <sbs root> with-block=true	rc=124, hangs	rc=0	rc=0

Three corrections to the brief, each measured

1. GetVolume and DeleteVolume are not defects. The SDK's own
getUnknownVolume (api/instance/v1/volume_utils.go) falls back to
block.GetVolume only on a typed 404 from the instance side, and scw's
-D trace of terminate takes exactly that pair. Making them resolve both kinds
would break the fallback — it is in the spec as a mutation, and it reddens
TestAnSbsRootVolumeIsReadableThroughTheBlockFallback.

So the five are three defects plus two doors that must stay shut.

2. detach-volume is a sixth, and it is the worst. It answered 200 and
released nothing, so scw instance server terminate … with-block=true polled a
block volume for a status that could never move: rc=124 at 25 s, five
identical block GETs in its own trace. Reachable today by anybody writing
root-volume=sbs:20GB.

3. A seventh, unlisted: attachTemplateVolumes silently skipped
additional-volumes.0=<a block volume> at create — 201 with the disk unattached.

Does step 1 make step 2 safe? Not as specified.

The gap was measured and closed rather than shipped on the brief's word.
Three things had to be added first:

• detach-volume, without which every terminate would hang after the flip;
• attachStoredVolume never marked a block volume in_use while
  detachStoredVolume had always marked it available — so an attached disk
  answered references: [attached] and status: available at once, and
  scw polls the status;
• Owns declared kindPrivateNIC and kindVolume and not kindBlockVolume,
  so storetest.Orphans — the sweep proving no disk names a dead machine —
  skipped every disk of one product, for as long as that product has existed
  here. Witness planted.

With those in, step 2 is one line, and it is safe.

And the fix broke something, which was then measured

Typing the instance snapshot of a block volume sbs_snapshot — straight off the
SDK enum — is not a label but a promise: scw instance image list calls
block.GetSnapshot for every image whose root_volume.volume_type says so, and
fails the whole listing on error (custom_image.go:222). An image cut from
such a snapshot made instance image list answer 404 for the entire zone.

It is unified now — the value the CLI itself sends for that input — and the
test asserts the promise, not the spelling.

#365, and a debt it had been hiding

scw block volume get <a default DEV1-S root>: 404 before, 200 after.

The 18 acceptance entries in corpus/accepted.json that carried it were
deleted from the gate's own output, never retyped — the staleness rule made it
compulsory. feint corpus --check now compares those exchanges for real: 0
divergent findings nothing accepts, 174 entries where there were 192.

Comparing them for the first time found two fields the cloud answers and this did
not, both served rather than accepted: parent_snapshot_id (the root disk
names the image snapshot it was restored from) and last_detached_at.

volumes_constraint.min_size is untouched, checked rather than supposed:
scw instance server create type=DEV1-S is the first thing the suite does, and it
passes.

Snapshots — measured, not fixed, and it is a decision

Same shape one product over, and step 2 put it on the default path:

	block snapshot	instance snapshot
block snapshot create volume-id=<server root>	works	n/a
instance image create snapshot-id=…	404	works
block volume create from-snapshot=…	works	404

A block snapshot is now the only kind you can take of a server's root disk, and
instance image create cannot cut an image from one — so the golden-image chain
is walkable from a client-created volume and no longer from the server's own
root. Real, not a choice: the SDK says images built on block snapshots exist.
docs/limits.md carries the table. The change was not widened to fix it.

Gates

prepush, conformance:leg -- scw-cli / fields / terraform / opentofu,
feint corpus --check — all green. 17 falsify specs, 17 mutations, 17 bit, 0
that did not, including the new block-volumes-reach-their-server.json.

Re-run at the end on the clean tree at 2b09d68 with zero uncommitted changes,
because the first batch overlapped with in-flight edits and its reds were the
copy's, not the code's.

What was not obtained

• mise run evidence:update — prescribed, not run: it starts machines and
  this lot was bounded to none. Measured reason it is safe to skip: the only
  coverage/ key this diff changes (ListVolumesTypes' decline reason) does not
  appear in coverage/evidence.json at all.
• limits:check is red, and was red before this branch — the #277
  per-parameter section, acknowledged 2026-08-27, with Scaleway renamed the VPC object-storage field on 2026-08-25 and the response body still answers the old name: the query parameter was fixed, the answer was not #570 closing today at
  12:45. That section is byte-identical here and on main; it was not re-dated,
  because refresh re-dates every section and that is a claim nobody earned.
• No cloud recording arbitrates whether the real instance.GetVolume answers for
  an SBS volume. docs/limits.md says so rather than guessing.

Where testplan was wrong

It prescribed FEINT_VM=incus-ovn conformance:leg -- runtime, which this
change cannot earn: it routes on servers.go importing internal/core/machine,
not on what the diff does. Measured — grep volume over
internal/providers/scaleway/machines.go, internal/core/machine/*.go and
internal/core/cloudinit/*.go returns zero hits: the machine layer never
reads a volume.

One incidental fix: scaleway-cloud-fidelity.json's volumesOf mutation became
ambiguous when anyVolume introduced a second identical loop header, and
falsify:lint refused it before this branch had a first commit. Retargeted at the
line only volumesOf has.