Add iMessage tapback removal to the SDKs and CLI

[alex-w-99]

Summary

Agents could send an iMessage tapback but never take one back. This adds removal to every surface, addressed by the reaction id that the send result and message reads already carry.

Surface	Call
Python	identity.remove_imessage_reaction(reaction_id)
TypeScript	await identity.removeIMessageReaction(reactionId)
Rust	identity.remove_imessage_reaction(&reaction_id)?
CLI	inkbox imessage unreact <reaction-id> -i <handle>

Each delegates to a new remove_reaction / removeReaction on the iMessage resource.

Two behaviors worth knowing, and the docstrings say both:

• Only the sender can take a tapback back. A reaction the other party sent is rejected.
• A tapback Inkbox already shows as gone succeeds without contacting the messaging network — whether you took it back already or a newer tapback replaced it. There is no "already removed" error to handle.
• A failed removal leaves the tapback in place rather than clearing it locally, so the call can be retried. Note what is not claimed: the retry re-issues the removal, and how the messaging network treats a removal for a tapback it has already dropped is not something the wording promises. An unconfirmed failure can therefore leave a reaction reading as live until a retry succeeds.

Version

0.6.1 → 0.6.2, in lockstep across sdk/python/pyproject.toml, sdk/typescript/package.json, sdk/rust/Cargo.toml, cli/package.json, and .claude-plugin/plugin.json — plus the two User-Agent constants (sdk/typescript/src/version.ts, cli/src/client.ts), the CLI's @inkbox/sdk dependency range, and all four lockfiles. Changelog entries are in CHANGELOG.md and the three per-package logs.

Additive only: no existing signature, argument, or return type changes.

Skills

inkbox-python, inkbox-ts, and inkbox-cli now show the removal alongside the send in their tapback sections, including the retry-safety note. The Python and TypeScript samples bind the send result so the id has an obvious source.

Testing

• Python — uv run pytest: 1066 passed, 3 skipped. New cases cover the DELETE path and a UUID argument alongside a string.
• TypeScript — npx vitest run: 77 files, 1077 passed, 3 skipped. New case asserts the method, URL, and that no body is sent.
• Rust — cargo test: all pass, including a new mocked 204 removal. cargo fmt --check and cargo clippy --all-targets -- -D warnings clean.
• CLI — npx tsc --noEmit clean after rebuilding the TypeScript SDK, and inkbox imessage unreact --help renders the command. (The CLI resolves types through a symlink to sdk/typescript/dist, so a stale local build reports errors for this branch and for Add agent contact sharing controls #154's contactSharingEnabled until you run npm run build in sdk/typescript.)

To try it against a live identity with iMessage enabled and a contact who has messaged first:

inkbox imessage react <inbound-message-id> -i <handle> --reaction like
inkbox imessage unreact <reaction-id> -i <handle>

The tapback appears and then clears on the recipient's device, and it drops out of the message's reactions on the next read. Running unreact a second time returns success without sending anything, since the reaction already reads as removed.

Requires

The removal endpoint must be live in the target environment. Against an older deployment these calls return 404.

Review follow-ups

• Package READMEs updated. They are what PyPI, npm, and crates.io render, and they still described tapbacks as send-only. All four tapback sections now show removal, and the CLI command list gains inkbox imessage unreact <reaction-id> -i <handle>.
• Garbled release-note sentence fixed in the root CHANGELOG.md.
• unreact now has a registration test alongside the existing react one, pinning the reaction-id argument and the required identity flag.
• Identity-level docstrings carry the sender-only clause, since that is the 422 callers will actually hit and the identity method is the one they use.

Left as-is: inkbox imessage unreact prints { id, removed } while the MCP tool returns { reaction_id, removed }. The CLI is internally consistent (react prints id), so changing it would be the odd one out.

[dimavrem22]

Approving — READMEs, changelog wording, unreact registration test, and the sender-only clause in the identity-level docstrings are all in. Publish 0.6.2 only once the removal endpoint is live in production.

[alex-w-99]

Thanks. Gate acknowledged: 0.6.2 goes out only after the removal endpoint is live in production — the READMEs, skills, and plugin manifest all describe behaviour that 404s anywhere it isn't.