Filter what `find` was handed, and refuse the search that cannot be ranked

Two more from Codex, and the second one led somewhere bigger than it was
aimed.

`find hf://<kind>/<owner> --name GLOB` is the row the captured README gives
`find` -- "Recursive name/path matching inside an owner namespace" -- and the
parser rejected both `--name` and `--path` by name. Now implemented. What
they match is the repository's LEAF name, probed rather than assumed:
`--name "deepseek-ai/*"` finds nothing on the live server where `--name
"DeepSeek-V4*"` finds every V4 model, and `--name "deepseek-v4*"` finds
nothing either, so the owner is not part of the string and the match is
case-sensitive. `--path` globs the same string at this scope. The bound moves
after the filter when one is given: pushed to the route it would cut the rows
before the glob saw them, and a match past the limit would vanish while the
listing reported itself complete.

Codex read `find` here as recursing into each repository's descendants. It
does not -- the live server answers repository rows at this scope, the same
rows `ls` answers, filtered.

`--sort` is now refused on `find`, which is its own grammar: the captured
line gives `--sort` to `ls` and `search` and not to `find`, and accepting it
was this branch's own invention.

`--kind mcp` was refused as an unknown flag. Probing what it does turned up
the larger fault: `search hf://spaces` is not the search the other two roots
get. It is SEMANTICALLY ranked, and every row carries `semantic
relevance=93.8%`, a classifier `category` and a `title`; the percentage moves
between calls for the same repository. This branch was answering that URI in
the plain listing shape -- a row no live server produces, which is the same
silent wrongness as an empty listing for `trending`.

So the bare `hf://spaces` root is refused with the reason, and only it:
`search hf://spaces/<owner>` IS the plain shape upstream and still answers.
That URI is also the only one where `--tag` and `--kind` apply, which is why
neither is served -- and off it they now earn upstream's own sentence,
"--tag and --kind are supported only with search hf://spaces", instead of
"unexpected argument". That rule is narrower than this branch had it: `--tag`
was being accepted on `search hf://datasets`, where the live server refuses.

329 checks, up from 315.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>