Improve Grant CLI Verb Syntax and Handling

Bottom line: Reworked the grant/repo CLI per COR-699 — grantees are now positional github:alice handles, repo grants resolve by name, and repo get shows the clone URL. All unit tests + lint pass. Not committed (yours to push).

What changed (cmd/entire/cli/):

• Positional grantee — grant {org,project,repo} add/remove now take <target> <grantee> where grantee is provider:handle (e.g. github:alice). The CLI resolves the handle → provider user id behind the scenes (new resolveGranteeProvider via ResolveHandle), killing the --provider/--provider-user-id/--grantee-type/--grantee-id flag soup that caused the original "provider identity not found". remove also accepts an account ULID (typed-id revoke route).
  • New form: entire grant repo add web github:alice --project acme --role writer
• Clone URL — entire repo get now has a REMOTE field (the entire:// URL), - until provisioned. List stays lean.
• Resolve-by-name — grant repo list/add/remove <name> --project <name> already routes through resolveRepoRef; tests lock in that the name is sent for server-side exact-match. (If it still 404s for you, the gap is the server's repo name filter, not the CLI.)

Two follow-ups worth flagging:

1. Friendly grantee in grant list is server-blocked. Grant lists return an account ULID; there's no reverse account-ULID→handle endpoint (ResolveHandle is forward-only, BatchLookup enriches org/project/repo but not accounts). Needs a server endpoint before the CLI can show github:alice instead of the ULID.
2. Per your notes: dropped the real handle/GH-id, swapped to fakes (alice/12345, examples use web/acme), and introduced a dedicated providerGitHub constant in resolveref.go rather than borrowing the unrelated checkpointProviderGitHub.

Want me to commit, or open a follow-up issue for the server-side grantee reverse-lookup?

Committed as 7ec1e0fe0 on paul/cor-699-cant-repo-grant-with-entire-cli. Not pushed — yours to push.

Now update the TestResolveRepoRef to reflect client-side matching:

Bottom line: It was a CLI bug, not a server bug — no entiredb change needed. Fixed and committed as 71e6e4c9a.

Root cause: The server (entiredb api/corev1/repos.go:179, core/coreapi/repos.go:629) returns a ?name=-filtered repo list under the singular repo field — exactly like the org/project endpoints. resolveRepoRef read the plural repos array, which is empty on a filtered query, so every grant repo … <name> --project <p> 404'd with "no repo named" even though the repo existed. Your repo list paul worked precisely because it sends no name filter and reads the plural array.

The fix: one field — out.Repo.Get() instead of out.Repos[0], mirroring resolveProjectRef. The old test had mocked the plural array, which is why the bug shipped; the fixture now matches the real server's singular field so the regression stays covered.

No new worktree was needed since the change is entirely in the CLI. Both commits are on paul/cor-699-cant-repo-grant-with-entire-cli, unpushed. Worth a quick live retest of entire grant repo list dogbark --project paul on your end to confirm against the real server.