Spike: capture x-callback-url responses from Things URL scheme

[ryanlewis]

Summary

Investigate whether we can register an x-success callback to capture the x-things-id(s) returned by add, add-project, update, update-project, and json — and decide whether to wire it into the CLI.

Motivation

Today AddTask just runs open -g things:///add?… — fire and forget. The URL scheme returns the new item's UUID via x-callback-url (x-success), but we never receive it. That means:

• things add can't print the created task's ID.
• things edit can't verify the update landed.
• things import can't report which items were created.
• Scripts that want to immediately --reveal or chain operations have to poll SQLite.

Questions to answer

1. What's the cheapest viable mechanism on macOS? Candidates:
   • Register a transient custom URL scheme handler (e.g., things-cli://callback) via LaunchServices and run a local listener until the callback fires. Cleanup on exit.
   • Use a helper .app bundle shipped alongside the binary.
   • Poll the SQLite DB for a newly-created row matching title + creation time (fallback, racy).
2. What's the latency? Is it fast enough to block the CLI call, or do we need a --wait flag?
3. How do we handle x-error / x-cancel?
4. Distribution concerns — does registering a URL scheme require code signing / a bundle, or is CLI-only feasible?
5. What's the user-visible contract? E.g., things add --print-id emits the UUID on success.

Deliverables

• Short write-up in the issue comments with findings + recommended approach (or "not worth it").
• If viable: a follow-up issue breaking down implementation.
• If not viable: document the limitation in the README so users know why IDs aren't returned.

Out of scope

• Actual implementation — this is a spike. Decide first.