Scaleway: an attached public IP publishes no gateway and drops its own tags

[stephrobert]

What was measured

A flexible IP (type=routed_ipv4, tags.0=feint-corpus) reserved on a real
Scaleway account in fr-par-1 on 2026-08-21 and attached to a DEV1-S at create
time. Recorded through feint proxy --record, committed as
corpus/scaleway/scw-instance.jsonl. The cloud's answer, on the create, the
read and the update alike:

"public_ips": [{"address": "…", "dynamic": false, "family": "inet",
                "gateway": "62.210.0.1", "id": "…", "ipam_id": "…",
                "netmask": "32", "provisioning_mode": "dhcp",
                "state": "attached", "tags": ["feint-corpus"]}]

Two values this emulator does not produce, in public_ip and in every element
of public_ips:

• gateway is a string on the cloud and null here. A routed IP has a
  gateway, and the address is what a guest needs to route off-link.
• tags carries the IP's own tags on the cloud and is empty here. The tags
  were sent on CreateIP and the cloud propagates them into the server's view
  of the address; this emulator answers [].

Why this is one issue and not two

Both are the same view — the rendering of an attached address in
internal/providers/scaleway/ips.go — and the same cause: the emulator
publishes an address without the two attributes the cloud attaches to it.
Splitting them would produce two patches to one function.

Where it is recorded today

corpus/accepted.json, twelve entries — three operations x (public_ip and
public_ips[]) x (gateway type, tags[] absence) — each naming this issue.

Related

Found by #352's chain, on the first recording that carried a billed resource.
The order of public_ips itself is #320's subject and is not divergent:
this recording is the first thing in the repository that exercises it, and it
matched.