Scaleway: every third-party VPC stack dies on /account/v3/projects before it reaches a VPC path

[stephrobert]

The premise #343 was written on, and what the measurement did to it

#343 asked for "at least one third-party Scaleway stack currently stopped on a
VPC or IPAM path" to reach its next wall. There is no such stack, and the
measurement that says so is the same one that closed #343's own scope.

Two independent third-party stacks that walk the VPC surface were fetched and
driven against this emulator through feint proxy --record on 2026-08-21:

• tf-scaleway-modules/terraform-scaleway-network @ 99f390bb (2025-12-25), a
  published Scaleway network module: VPC with routing and custom-route
  propagation, a scaleway_vpc_acl, private networks, public gateways with
  bastion, and one scaleway_ipam_ip per network-zone pair;
• srdp-hub/srdp @ 59cb6a7b, deploy/opentofu/scaleway/main.tf.

Both die in the same place, and it is not a VPC path. The whole recording of the
first one, its complete example, is two exchanges:

GET 501 /account/v3/projects
GET 501 /account/v3/projects

Error: scaleway-sdk-go: http error 501 Not Implemented:
       feint does not serve /account/v3/projects

  with module.vpc.data.scaleway_account_project.project,
  on .terraform/modules/vpc/data.tf line 26, in data "scaleway_account_project" "project":

data "scaleway_account_project" is evaluated before any resource, so nothing
downstream of it is ever attempted. The module's VPC, its ACL, its private
networks, its gateways and its IPAM addresses are all unreachable behind one
data source, and both stacks reach for it.

The fifteen surveyed stacks (examples/stacks/surveyed.md) agree from the other
side: not one of the five Scaleway ones is stopped on a vpc/v2 or ipam/v1
operation. Their walls are Object Storage, Kapsule, Tailscale and a placement
group, and #343's tally table names no VPC row at all.

Why this is not simply "serve one more route"

account/v3 is outside two committed lists, and both are deliberate:

• tools/drift/gate.sh scans instance,vpc,ipam,iam,marketplace,block,lb,vpcgw.
  Adding account puts the whole product under the gate, which means every one
  of its operations arrives untriaged and has to be declined with a reason.
• contracts/scaleway.json describes 370 operations and none of them is
  account/v3. TestEveryRouteMatchesItsContract refuses to mount a route the
  document does not describe, which is the same rule that keeps
  vpc/v2/API.EnableCustomRoutesPropagation declined today. So the contract has
  to be extracted first: one line in tools/contract/scaleway-products.txt, then
  mise run upstream:sync and mise run contract:update.

That is a product's worth of triage, and it is the honest shape of this work
rather than a route somebody forgot.

Done means

• account/v3 is in the contract and under the drift gate, every operation of it
  either served or declined with a reason, zero untriaged.
• ProjectAPI.ListProjects at least is served, because that is the one the data
  source calls.
• tf-scaleway-modules/terraform-scaleway-network's complete example reaches
  its next wall, and that wall is named here — the candidates the recording
  makes likely are vpc/v2/API.EnableCustomRoutesPropagation (declined: the
  portal's document does not describe it) and the vpcgw/v2 bastion fields.
• apply → empty second plan → destroy on whichever variant of that module
  clears.

Related

Successor to the half of #343 that had no subject. #343 closed the two vpc/v2
operations a client does reach (GetACL, SetACL) and left the rest declined
with the measurement written into their reasons; this is the wall standing in
front of all of them.