Missing: threaded reply with attachment (no flag combines --reply-to and --file)

[omarshahine]

What's missing

imsg today exposes two non-overlapping send paths:

• imsg send-rich --reply-to <guid> --text <text> — replies threaded to a target message, but does not accept --file.
• imsg send --file <path> (with --chat-guid/--to/--chat-id/--chat-identifier) — sends an attachment, but does not accept --reply-to.

There is no way to send a single message that is both attached to a file and threaded as a reply to an existing iMessage.

Why it matters

This becomes a real footgun for any orchestrator that exposes a generic "reply with media" surface. Concretely, on OpenClaw's iMessage extension we just shipped a bugfix (openclaw/openclaw#79822) because the high-level message tool was accepting `{ action: "reply", media: "" }` — a shape that genuinely makes sense for iMessage end-users — and silently dropping the media because there's no underlying `imsg` call that does both. Today the only correct path is two messages: a threaded text reply via `send-rich`, plus a separate `send --file` that is not threaded. Users see two bubbles, the attachment hangs in space, and most agents won't reconstruct the linkage.

Suggested fix

Either:

1. Add `--reply-to ` to `imsg send` (preferred — the AppleScript path that handles `--file` is the one most callers use), or
2. Add `--file ` to `imsg send-rich` (so the IMCore bridge writes the attachment and the reply pointer in one round-trip).

Option 1 is probably easier to land — Messages.app's AppleScript bridge can target a reply via `set targetService` / `set theMessage` patterns; option 2 needs the IMCore reply payload to carry an attachment GUID, which is more invasive.

Repro

```
imsg send --chat-guid 'iMessage;-;+15555555555' --file /tmp/foo.png --reply-to AAAAAAAA-...

error: unknown option '--reply-to'

imsg send-rich --chat 'iMessage;-;+15555555555' --reply-to AAAAAAAA-... --text 'here it is' --file /tmp/foo.png

error: unknown option '--file'

```

Tested on `imsg 0.8.0` on macOS 26.4.0 (Tahoe), IMCore v2 bridge, SIP disabled.

Current OpenClaw workaround

After openclaw/openclaw#79822, OpenClaw's `reply` action explicitly rejects `media`/`mediaUrl`/`filePath`/`buffer` and tells callers to use `upload-file` (untreaded) for the attachment. That keeps the silent failure from happening, but it means agent-driven "reply with image" still produces a non-threaded attachment — which is a subset of what users intuitively expect. A single-call `imsg` primitive would let us close that gap.

Happy to test a candidate flag locally if useful — I'm running this against a live OpenClaw + Lobster agent setup that hits the path daily.