client get and client delete act on the wrong client

[jorisvilardell]

Describe the bug

client get and client delete act on the wrong client. ferris-ctl client delete zukquote-realm deleted security-admin-console instead — the confirmation prompt showed the name that was asked for, not the one that was about to be removed.

Root cause

get_client builds GET /realms/{realm}/clients?clientId={id} and keeps the first element of the response (libs/ferriskey-cli-client/src/lib.rs:329-340). The server declares no query parameters on that route, so the filter is ignored and the CLI always receives — and keeps — the realm's first client.

delete_client resolves its UUID through that same call (libs/ferriskey-cli-core/src/client.rs:121-127), which is what makes the mismatch destructive.

Steps to reproduce

1. ferris-ctl client get zukquote-realm → answers with security-admin-console
2. ferris-ctl client delete zukquote-realm → deletes security-admin-console

Expected behaviour

The CLI must filter the returned list on client_id client-side rather than trusting a parameter the server ignores, and fail with "client not found" when no entry matches. The confirmation prompt should display the resolved client's id and UUID, so what is shown is what is deleted.

The server-side half is tracked in ferriskey/ferriskey (GET /realms/{realm}/clients accepts no filter); the client-side filter is worth having regardless, since it does not depend on a server upgrade.

Environment

ferris-ctl 0.2.3, FerrisKey server 0.7.0

[jorisvilardell]

Server-side half: ferriskey/ferriskey#1288 (GET /realms/{realm}/clients ignores the clientId filter).