feat(iam): show what an API key can do, and take a tag off a resource

[Denis-hamon]

Stacked on #266. The reviewable unit is the last commit.

The grid in the product note scores "Authentication and access management" 2/5,
the widest remaining gap against the panel. Its stated reason is half out of date —
logout shipped in #228, and the CLI pushes no token, it collects an application key
the operator created elsewhere. The real gap is narrower and sharper: nothing in the
CLI shows what a key can do, and nothing can take a tag off a resource.

ovhcloud iam credential list [--status] [--application] [--unused]
ovhcloud iam credential get <id>
ovhcloud iam credential delete <id>
ovhcloud iam application list|get|delete <id>
ovhcloud iam check <action>... --on <urn>...
ovhcloud iam reference actions [--type] [--category] [--search]
ovhcloud iam reference resource-types
ovhcloud iam resource tag set <urn> <key>=<value>...
ovhcloud iam resource tag remove <urn> <key>...
ovhcloud iam user enable|disable <login>

What the account looks like once you can see it

66 API credentials, none of them visible from the CLI before this patch:

never used	17
never expire	44
restricted to an IP	2
can call the whole API	38

That last row is why scope is a column rather than a rule count: 139 of the rules on
this account are on /*, and "4 rules" would have read as narrow. A key that holds
GET POST PUT DELETE on /* is reported as whole API: DELETE,GET,POST,PUT.

--unused exists because of the first row. A key that has never been used, never
expires and works from anywhere is the one to revoke first, and the CLI could not
even list it.

Fine-grained tagging — the premise was wrong, and the real gap is worse

The plan for this lot said iam resource edit --tag sends a PUT that replaces the
whole tag map, silently. Measured, and it does not. common.EditResource GETs the
resource and merges before it PUTs, so the tags already there survive. That is the
eighth audit premise this series has had to correct with a measurement.

The raw API does replace — posting two tags then PUTting one leaves exactly one —
so the merge is real work done by the client, over two calls, with an edit landing
between them being lost. That is worth knowing but it is not the gap.

The gap is that nothing can remove a tag. Measured on a real resource:

attempt	result
edit --tag owner=x with a shorter list	nothing removed — merging means a short list removes nothing
edit --tag only= with an empty value	{"only": ""} — a tag that looks removed and is not
tag remove only	actually removed

So tag set and tag remove are the only way to take a tag off a resource, and set
posts one tag at a time without reading the others first — no read-modify-write, no
window for a concurrent edit.

iam check, and why it is the most useful command here

It is a POST that writes nothing, and it answers the question a permission error does
not: which of these actions are allowed, on which resource. Both directions verified
against the API:

$ ovhcloud iam check dedicatedServer:apiovh:get vps:apiovh:reboot --on urn:...:ns****
| resource                        | action                     | allowed |
| dedicatedServer:ns****          | dedicatedServer:apiovh:get | yes     |
| dedicatedServer:ns****          | vps:apiovh:reboot          | no      |

One unknown action fails the whole batch, and the API's 400 does not say that. A
typo in the fourth action therefore reads as "the check does not work". The refusal is
translated: it says one bad name sank the rest, how many went unanswered, and where to
find the real names.

The action reference refuses to print itself

9158 actions across 117 product families — dedicatedServer alone has 183. A table
of nine thousand rows is not an answer, so past 400 matches the command says how to
narrow instead. --type is sent to the API; --category and --search are applied to
what comes back, because the API filters on neither.

Verification

Gate green on the five steps.

Three of the first eighteen sabotages did not do their job, and each was worth the
detour. One came back green: the dry-run of credential delete was tested and the
guard was not — the half that actually stops a mistake. Two broke the build,
which proves nothing about a test's teeth; re-aimed so they compile, both bite. Fixing
the first also surfaced a defect in the product: tag set --dry-run printed the same
POST line once per tag and never said which tag, because common.Call carries no
body on this stack. A preview that cannot be told from another preview is not a preview.
41 tests (21 unit, 20 cobra) and 19 sabotages, 19 red, with restoration verified by checksum.

Run against the real API: the credential listing and all three filters, the refusal of
an unknown status, check in both directions and with an unknown action, the reference
with and without a filter, and the full tagging cycle on a designated test server —
set, set again, the old edit --tag alongside it for comparison, remove, and the
refusal of an absent key. The server's tags were read outside the CLI before and
after, and are back to null.

The credentials live in /me while the rest of IAM is v2. They are placed under iam
because Scaleway, AWS and gcloud all keep API keys under their identity command, and
because an operator asking "what can this key do" looks where the policies are. Nothing
existing is moved.

Not in this patch

/me/identity/group (22 groups) and the rest of the identity directory: exercising the
write paths means creating real users and groups on a production account, which the
tagging tests did not require. Its own lot.

Tags prefixed ovh: are computed by OVHcloud. They exist on this account — ovh:default
on a billing account, ovh:whoisOwner on domains — but on no dedicated server, so
what a write does to them could not be exercised within the authorised scope. Stated
rather than assumed.

[Denis-hamon]

Human review — Does not work

O5 · You could not remove a tag
Dimension: Product fit

Expected: iam resource tag remove is the only action that removes for real. Does the ghost-tag trap deserve a warning inside edit?

🛑 failed to read the tags of urn:v1:eu:resource:dedicatedServer:ns31633811: OVHcloud API error (status code 404): Client::NotFound::RESOURCE_NOT_FOUND: "resource not found" (X-OVH-Query-Id: EU.ext-5.6a8b854b.1090988.2b41961fca552531612672aa118a07fd)
Check the URN with: ovhcloud iam resource list
exit 1

— Denis (Product Manager), through CLI sandbox review page

[Denis-hamon]

Human review — Does not work

O5 · You could not remove a tag
Dimension: Product fit

Expected: iam resource tag remove is the only action that removes for real. Does the ghost-tag trap deserve a warning inside edit?

🛑 failed to read the tags of : OVHcloud API error (status code 400): Client::BadRequest::INVALID_PARAMETER: "invalid resource identitifer" (X-OVH-Query-Id: EU.ext-4.6a8c69e1.541833.f7c7a07d11b58bf2ca1ca67851c023e0)
Check the URN with: ovhcloud iam resource list
exit 1

— Denis (Product Manager), through CLI sandbox review page