fix(add): accept any list sharing the requested title in the read-back

[ryanlewis]

Fixes from a `/code-review high` pass over main since v0.9.0. The two serious ones are false failures in the add/import read-back: the item is created, but the CLI exits non-zero with "do not retry blindly".

• Shared list titles: when several open projects (or areas) share the requested list title, the read-back accepted only the one AddTarget picked. Which one Things picks isn't known, so a correct add could fail. Add and import now accept a new item in any list with that title (`db.ListTitleShared`, which counts matches the way AddTarget does).
• uuid in an import's `list`: Things matches `list` by title, so an item whose `list` holds a uuid lands in the Inbox. The read-back used to check it against that project and fail. It now leaves that item's destination unchecked, as it already does for an unknown list.
• Untrimmed area key: project add trims the area title before folding, matching how rows are compared.
• Checklist order: checklist reads order by index then uuid, so the edit read-back's row-by-row compare can't flip on items that share an index.
• project add reuses the areas it already read, `update` passes `d.in()` to the child process, and the row-number block in `resolveTask` only runs for row refs. None of these change behaviour.

Tests: `TestAddSharedListTitleFitsEither` (3 of its 5 cases fail without the fix), plus `uuidAsList` and `sharedAreaTitle` cases in `TestImportCreatedChecksDestination`. `make test` and `make lint` pass after rebasing onto 63a3f9a. Not checked in real Things.

Docs: `docs/content/agents.md` and `internal/skill/SKILL.md` describe both read-back changes.