[ryanlewis]

resolveRef built its own refusals for row numbers, row-like refs (#12, 07) and uuid-shaped refs, and they all said "task". So open --project 99 and project edit <unknown uuid> reported a task not found, while a title miss already said project (#444, #445).

resolveRef now picks one noun ("task", or "project" for a project lookup) and every refusal uses it, in the message and in the JSON kind:

• not found: a row past the last list, a stale row, a row-like ref, a uuid-shaped ref
• stale list cache (old listing, other database, unreadable cache file)
• empty reference
• ambiguous task (the token stays the same; the text and kind say project)

Task lookups print exactly what they did before.

Example

$ things open --project 99
Error: no project is titled "99", and there is no last list for it to be a row of. Re-run your listing and use the row number, or pass the project's uuid or full title.

Tests

TestRunProjectRefNotFoundKind covers the four not-found shapes on open --project and project edit (all eight cases fail on main). TestRunProjectRefRefusalKind covers a stale row, an empty ref and an ambiguous ref.

SKILL.md and docs/content/agents.md now say these refusals carry kind project.

Follow-ups (not in this PR)

• resolveProjectRef only falls back to the to-do check on db.TaskNotFoundError. So a to-do titled exactly #12 or 2026 gives project not found for project edit '#12' where a plain title gives not a project.
• A stale row now says "project fix(deps): update module github.com/mattn/go-isatty to v0.0.21 #2 no longer exists" even when row 2 came from a task listing such as today.