feat(ip): move a failover IP, and say where it can go

[Denis-hamon]

Stacked on #254. Only the last commit belongs to this pull request.

First of three on the ip domain, which the CLI reaches by 15 routes out of 81.

An additional IP is bought to be moved

That is what makes it additional: it follows a service rather than a machine,
so a failover survives the server under it. The CLI could list those IPs and
show what each was routed to, and could move none of them.

ovhcloud ip destinations <ip>
ovhcloud ip move <ip> <service> [--nexthop] [--wait] [--yes|--dry-run]
ovhcloud ip park <ip> [--wait] [--yes|--dry-run]
ovhcloud ip tasks <ip>

destinations is what makes the rest usable

The API answers a map keyed by service family. On a real account, one address
accepted a hundred destinations — 33 cloud projects, 33 VPS, 22 dedicated
servers, 12 load balancers. Families that accept nothing come back as empty
lists rather than being absent, so they are dropped: four empty sections answer
the question worse than three full ones.

🎯 135.125.71.80/32 can be moved to

**33 cloudProject · 22 dedicatedServer · 12 ipLoadbalancing · 33 vps**

 Family           | Service                          | Next hop
 cloudProject     | 036c08c8817b47809b9c3a7756006f4c  | 91.134.205.200, 91.134.205.6
 dedicatedServer  | ns3118333.ip-51-68-100.eu         |
 …

The destination is checked before the request

$ ovhcloud ip move 135.125.71.80/32 ns-inexistant.example
🛑 ns-inexistant.example does not accept 135.125.71.80/32.
   It can be moved to 33 cloudProject, 22 dedicatedServer, 12 ipLoadbalancing,
   33 vps — list them with: ovhcloud ip destinations 135.125.71.80/32

The alternative is a 400 several seconds later with no hint of which names
would have worked, and the CLI is holding that list already. The individual
services are deliberately not printed — there can be a hundred — so the
refusal names the command that lists them instead.

The guard is Disruptive. What stops is the traffic of the service the IP is
leaving, and that service is the one thing the operator cannot see from the
command they typed, so the prompt names it.

--wait reads the IP, not the task

Measured during the live move: a minute after the API accepted the request,
the task existed with status todo and routedTo still pointed at the old
server. A wait that trusts the task it was handed can report success while the
work is unfinished — the same shape as #249, where one vRack attach produced
two tasks.

Verified on a real failover address, moved and put back

step	measured
move to ns3118333.ip-51-68-100.eu --wait	1 min 32 s, exit 0
move back to ns3018397… --wait	1 min 06 s, exit 0
final state, read outside the CLI	identical to the start

The four refusal paths were run against the live API: unknown destination,
--dry-run, an IP that serves nothing, and refusal without --yes.

go build, go vet, make wasm, go test ./..., docgen — all green.
13 tests. 5 sabotages, 5 red, each on the test meant to catch it.

One of those sabotages first reported red for the wrong reason — it left an
unbalanced brace, so the failure came from the compiler rather than from a
test. Re-applied in a form that compiles, it fell on the intended test. Every
restore in this lot is verified by checksum against the pre-sabotage file.

Note for whoever merges this with #242

common.Call gains a Detail field in #242, which is not in this branch's
ancestry. The move's destination therefore travels inside the endpoint string
here; when both land, it belongs in Detail so that -o json keeps endpoint
a path. There is a comment saying so at the call site.