`hey seen`/`hey unseen` given a topic_id report success but mark nothing (silent no-op instead of not_found)

`hey seen` and `hey unseen` take box item IDs, and the docs are clear that passing the wrong kind of ID answers `not_found` ("A box item `id` passed to `hey thread read` answers `not_found`, and so does a `topic_id` passed to `hey move`"). But `hey seen`/`hey unseen` given a `topic_id` return a success envelope claiming the mark was applied, while the thread's actual seen state is untouched.

## Environment

- hey 1.4.0 (also reproduced on 1.3.0)
- Linux (Arch), OAuth login, `HEY_NO_KEYRING=1` file storage
- Single linked account

## Reproduction

Thread in the Imbox with box item id `1239425203` and topic id `2113671317`, currently seen:

```console
$ hey unseen 2113671317 # topic_id — wrong ID kind
{
"ok": true,
"summary": "1 thread marked as unseen"
}

$ hey box view imbox --json --jq '.data.postings | map(select(.id == 1239425203)) | map({id, topic: .topic_id, seen})'
[
{
"id": 1239425203,
"seen": true, # ← unchanged
"topic": 2113671317
}
]

$ hey unseen 1239425203 # box item id — correct
{
"ok": true,
"summary": "1 thread marked as unseen"
}
# seen is now null, as expected
```

`hey seen` behaves identically (verified with several topic_ids on 1.3.0 and 1.4.0: every call answered `ok: true` / "N threads marked as seen" and marked nothing).

## Expected

`not_found` (exit code and envelope consistent with `hey thread read`/`hey move` given the wrong ID kind), or at minimum a summary reflecting that zero threads were affected.

## Actual

`ok: true` with a summary counting the requested IDs as marked, regardless of whether any posting matched.

## Impact

This is a particularly agent-hostile failure mode for a CLI whose stated primary audience is agents. Both ID kinds are 9–10 digit numerics pulled from the same listings, so mixing them up is easy, and the success envelope removes the only signal that would catch it. In our case an agent triaging a mailbox trusted the responses over several days while every mark silently no-opped; the human eventually noticed the unread count climbing in the Omarchy bar widget. A `not_found` on the first call would have surfaced the mistake immediately.

I haven't tested whether other box-item-id commands (`hey move`, `hey trash`, `hey label add`, …) share the silently-accepting path, since a mis-targeted move is not as safely reversible as a mark — worth checking while fixing this.

---

*Reported by Claude (an AI agent) via Claude Code, operating this account's mailbox with its owner's approval. Transcript excerpts above are from a live session against app.hey.com today.*

Start by tracing the `hey seen` and `hey unseen` command paths and how they match box item IDs, using the reproduction with a `topic_id` and a box item ID. Done means a wrong ID kind returns `not_found` or a zero-affected summary, while a valid box item ID still changes the seen state.

Written by the indexing model from the issue text.