runtime/claude_code: materialize image blocks to tmpfile + extract image_cache module

[benhoverter]

Summary

Makes inbound image ContentBlocks viewable by the Claude Code CLI driver, which cannot fetch URLs or read in-memory bytes — it can only Read files on disk. Images are now materialized to a content-addressed tmpfile under $HOME/.openfang/tmp/images/ and the directory is granted to the CLI via --add-dir. Also extracts the cache into a sibling module so future producers (outbound Discord) can reuse it.

Four commits, no merge commits, builds clean workspace-wide.

Commits

1. 1203647 runtime/claude_code: materialize images to tmpfile so the CLI's Read tool can view them
   Adds tmpfile materialization in the claude_code driver. Also introduces ContentBlock::Image::source_url: Option<String> in openfang-types and threads it through every consumer (api, channels/bridge, all four model drivers for pattern-match exhaustiveness, agent_loop, compactor). The field is wired through serde and matches but is not consumed by any driver on this branch — it is the load-bearing schema change for the rest of the series and for outbound Discord (separate PR). Includes a regression test (bridge::tests::download_image_to_blocks_populates_source_url) asserting source_url is populated on the HTTP fetch path.

2. 021c6df fix(runtime/claude_code): atomically publish materialized image tmpfiles
   Replaces the non-atomic fs::write with write-tmp + rename(2). Closes a torn-file window where a re-render racing a Read tool call could read a partially-written image. Orphan .tmp files are reaped by the existing 24h TTL sweep.

3. 46e5c8c fix(runtime/claude_code): pass --add-dir for materialized image tmpfiles
   The CLI's Read tool refuses paths outside the agent workspace unless --add-dir'd (we don't want --dangerously-skip-permissions as the only escape hatch). Adds the grant to both streaming and non-streaming command builders. The directory is per-user and content-addressed, so the grant is narrow.

4. c93318f refactor(runtime): extract image_cache module
   Lifts the cache helpers (image_tmp_dir, ext_for_mime, materialize_image, sweep_old_image_tmpfiles, IMAGE_TMP_TTL_SECS, sweep guard) out of the driver into crates/openfang-runtime/src/image_cache.rs. No behavior change — extracted helpers are byte-identical. Module is pub so channel adapters can resolve cached paths from base64 image blocks before forwarding them outbound.

Notes for reviewers

• Trivial textual conflict with fix(channels/discord): surface image attachments to text-only providers #1143. Both branches edit download_image_to_blocks in crates/openfang-channels/src/bridge.rs — fix(channels/discord): surface image attachments to text-only providers #1143 added file:// support; this PR sets source_url on the resulting ContentBlock::Image. The conflict is mechanical (one extra field on a struct literal) and I'll resolve it on whichever branch lands second.
• source_url field added but not read on this branch. It's wired through serde and every pattern match for type-safety, but no driver consumes it here. The consumer ships in the outbound-Discord PR (forthcoming) where it lets us round-trip a Discord CDN URL back to Discord without re-uploading bytes.
• Scope is runtime-only. No Discord, no channel-adapter behavior changes (the bridge.rs edit only sets the new field on download).

Test plan

• cargo check --workspace clean (only pre-existing imap-proto future-incompat warning)
• cargo test -p openfang-channels --lib clean (477 passed)
• Inbound image via Discord URL → Claude Code driver materializes → CLI Read succeeds (validated end-to-end with a real receipt image; daemon log confirms materialization + CLI describes contents)
• download_image_to_blocks populates source_url on the resulting ContentBlock::Image (new regression test, bridge::tests::download_image_to_blocks_populates_source_url)

Atomicity (commit 2) and the 24h TTL sweep (commit 4) are verified by code inspection: rename(2) is POSIX-atomic and the module extraction is byte-identical with no call-site change.

[jaberjaber23]

Code review LGTM. Real fix for a real driver limitation, atomic publish, mtime refresh, the file:// gating in compactor is a nice security touch, and the tests are solid (mtime refresh + sweep regression both covered).

Two things before merge:

1. Conflict with fix(channels/discord): surface image attachments to text-only providers #1143 (now merged on main). You called it out; needs a rebase. The mechanical bits: ChannelContent::File now has mime/size fields, and download_image_to_blocks already supports file:// — just need to keep your source_url assignment on the blocks.push.

2. image_tmp_dir() on Windows: only checks $HOME, which is unset in Windows daemon installs. Falls back to std::env::temp_dir() which works but the dir lives under temp, not under .openfang/tmp. Consider USERPROFILE as a fallback before temp_dir, matching the kernel's existing convention. Not a blocker, just consistency.

Rebase and I'll merge.

[benhoverter]

Rebased onto acf2587 (current main, includes #1143) and addressed both review items:

• Rebase: ChannelContent::File mime/size + file:// support in download_image_to_blocks integrated; our source_url assignment preserved on the blocks.push. Also picked up the new RedactedThinking variant in claude_code's no-op match arm and switched a few Message { … } test initializers to ..Default::default() to accommodate upstream's added msg_id/provider_msg_id fields.
• Windows fallback in image_tmp_dir(): order is now OPENFANG_TMP_DIR → HOME → USERPROFILE → std::env::temp_dir(), matching the kernel convention in drivers/mod.rs.

cargo check --workspace clean. cargo test -p openfang-runtime -p openfang-channels -p openfang-types: 1890/1890 passing, including the regression test download_image_to_blocks_populates_source_url (channels) and the three source_url round-trip tests in compactor.rs.

Ready for another look.