`tag add` exits 0 when the tag doesn't resolve, so a silent no-op looks like success

Start by reproducing the unresolved-tag and field-name cases with the tag add and set-field CLI entry points described in the issue. Trace how each command maps resource failures to output and exit codes; done means an unresolved tag exits non-zero and the field-name failure identifies the field resource rather than the node.

supertag 2.5.11 · macOS · local API on 8262

supertag tag add takes a tag id but not a tag name. Hand it a name it can't resolve and it does
nothing, prints a ! line, and exits 0.

$ supertag tag add -- <nodeId> decision
Added tag to My Node (<nodeId>):
  ! : Tag not found: decision
$ echo $?
0

The node is unchanged. The header still says Added tag to ....

By id it works, and exits 0 the same way:

$ supertag tag add -- <nodeId> pKEm-8D4yEhR
Added tag to My Node (<nodeId>):
  + decision: Added tag "decision"
$ echo $?
0

Same exit code for "did the thing" and "did nothing." The only difference is + vs ! inside the
body text.

Why I think it's unintended

The same command already exits 1 when the node doesn't resolve:

$ supertag tag add -- ZZZnotarealnode decision
Error [NODE_NOT_FOUND]
Resource not found: http://127.0.0.1:8262/nodes/ZZZnotarealnode/tags
$ echo $?
1

Same command, same kind of failure — an argument that didn't resolve — and one exits 1 while the
other exits 0.

The name isn't obviously bad input, either. supertag schema show -- decision resolves that exact
string to pKEm-8D4yEhR. One subcommand takes the name, another ignores it without saying so.

Why it matters

I run tag writes through a queue that marks a row applied on exit 0. So silent no-ops got recorded
as successes, and nothing anywhere reported a failure.

When I swept the ledger, 3 of 9 tag operations had never applied. Every one was a case where a name
reached tag add instead of an id. The oldest had been wrong for three days before I caught it —
that's the part that bothered me, because there was no signal to catch.

I've worked around it since (resolve names to ids first, then verify by reading the node back), so
I'm not blocked. Filing it because anything else driving the CLI would hit the same thing and might
not go looking.

Suggested fix

Exit non-zero when a requested tag fails to resolve, matching the node-not-found path. Resolving
names the way schema show does would also solve it, if you'd rather go that way — the exit code is
the part that matters for scripting. Happy to send a PR if that's useful, and equally happy to leave
it with you.

Smaller second thing: set-field by field name reports the wrong resource

set-field needs --field-id. Given a field name it fails with NODE_NOT_FOUND, pointing at a
path that ends in the field:

$ supertag set-field -- <nodeId> Confidence 4
Error [NODE_NOT_FOUND]
Resource not found: http://127.0.0.1:8262/nodes/<nodeId>/fields/Confidence/content
Suggestion: Verify the node ID or resource path exists in Tana.

$ supertag set-field --field-id 8miZmkfUaRgB -- <nodeId> Confidence 4
Set field on node <nodeId>
  Field: 8miZmkfUaRgB
  Value: 4

The node exists, carries the tag, and has that field defined — the id form works on the same node one
line later. The error and the suggestion both point at the node, so I went and verified a node that
was never the problem.

This one fails loudly, which is what counts. The message is what sent me the wrong way.

Open to anyone else who's scripting against the CLI if you've hit either of these differently.