feat: tags that don't exist are silently dropped on add/edit — warn, and support creating them

[ryanlewis]

Reported while tagging a task from another project — passing a tag that does not yet exist in Things resulted in silent data loss: the task was created, but the tag was missing with no warning.

Problem

Write commands pass --tags / --add-tags straight to the Things URL scheme (internal/things/urlscheme.go:33 — v.Set("tags", params.Tags)). The Things URL scheme only applies tags that already exist and silently ignores unknown ones — it does not create them. So:

things add "x" --tags "Work,cifas-auto-reject"

applies Work (exists) and silently drops cifas-auto-reject (does not). No error, no warning, exit 0.

There is currently no way to create a tag (TagsCmd is list-only — cmd/things/main.go:185 runTags → ListTags), so this is easy to hit and easy to miss.

Proposed change

Two parts; (1) is the cheap safety win, (2) is the real fix:

1. Warn on unknown tags. Before an add/edit that sets tags, diff the requested tags against db.ListTags() (internal/db/tags.go:9) and emit a warning naming any that do not exist (and were therefore dropped). Optionally a --strict-tags to exit non-zero. Turns silent loss into a visible signal with almost no risk.

2. Support creating missing tags. The URL scheme cannot create tags, but the repo already shells to AppleScript (internal/things/applescript.go), and Things AppleScript appears able to create tags as a side effect of setting tag names on a to-do (to verify). Options:

   • a dedicated things tag add <name> command, and/or
   • a --create-tags flag on add/edit that ensures requested tags exist (via AppleScript) before applying.

Acceptance criteria

• Passing an unknown tag to add/edit no longer fails silently — at minimum a clear warning naming the dropped tag(s).
• A documented, working way to create a tag from the CLI (command or flag), or a clear decision + README note that tag creation is a Things platform limitation if the AppleScript route proves unworkable.
• README documents the existing-tags-only behaviour of the URL scheme either way.

Evidence / pointers

• URL scheme tag passing: internal/things/urlscheme.go:33
• Tag listing (for the diff): internal/db/tags.go:9 ListTags
• Existing AppleScript helper to build on: internal/things/applescript.go
• Tags command is list-only: cmd/things/main.go:185