feat(lark): support inbound message attachments

[aihes]

Summary

• persist every inbound Feishu event before ACK, then process it with leased, restart-safe, conversation-ordered workers
• ingest image, file, audio, video, and rich-text embedded resources through the scoped message-resource API
• stream validated resources to LocalStorage or S3 and atomically bind attachments to the user chat message before scheduling the agent
• preserve successful resources on partial failure, retry transient failures, and fail open with a safe non-empty attachment notice after three attempts

Why this is separate from #5482

#5482 handles only images and still performs blocking work on the ACK path. This implementation covers all supported Feishu resource shapes, moves network and agent work behind a durable queue, enforces identity/membership/@bot checks before download, streams 100 MB resources without buffering them twice, and commits the message, attachments, and dedup marker in one transaction.

Security boundaries

• only message IDs and resource keys parsed from the signed event are accepted; no arbitrary URL input
• downloads happen only after installation, binding, membership, and group mention validation
• filenames are sanitized, object keys are generated, MIME is sniffed, and per-resource/message limits are enforced
• errors and terminal queue rows do not retain tokens, resource keys, absolute paths, raw upstream responses, or raw payloads
• this only exposes chat attachments to the existing agent attachment workflow; it does not auto-copy files into a knowledge base

Verification

Passed locally on PostgreSQL 16:

• make sqlc
• go test -race ./internal/integrations/lark ./internal/integrations/channel/engine ./internal/storage
• go vet ./...
• make test
• git diff --check

make check passed TypeScript typecheck, all TypeScript unit tests, all Go tests, and 24/29 Playwright cases. Five unrelated existing E2E cases (MCP Apps visibility, one issue grouping assertion, and two settings flows) failed unchanged by this backend-only branch; PR CI is the clean-environment gate.

No production Bot credentials or long connection were used for local testing.

Closes #5579

[vercel]

@aihes is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.

[Bohan-J]

Thanks for this — and I want to be straight that closing it is a sequencing outcome, not a verdict on the work.

We've merged #5580 for inbound Feishu/Lark media. Because it touches the same files with a different architecture, this PR can't be rebased into anything close to its current shape, so I'm closing it rather than leaving it to rot with growing conflicts.

Two things here that the merged version genuinely does not do, and I don't want them lost:

1. file and audio message types. fix(lark): ingest inbound images and videos as chat attachments (MUL-4934) #5580 covers standalone image, media/video, and rich-text post-embedded img/media spans only — mediaResourcesFromMessage returns nil for everything else. Your PR covered the full set of resource shapes. Feishu group bot does not pass ZIP attachments to bound agents #5887 (Feishu group bot not passing ZIP attachments) is the open issue for exactly this gap.
2. Persisting the inbound event before the ACK, with leased, restart-safe, conversation-ordered workers. The merged design instead keeps the message write on the inbound path and moves only media resolution to a detached worker, with an intent ledger plus reconciler for the object-storage/DB atomicity problem. Yours is a stronger guarantee for the event itself; that trade-off wasn't consciously chosen against your design, it just wasn't the branch under review.

Your read on #5482 was also correct — images-only plus blocking work on the ACK path was the right thing to flag, and the ACK-path concern is precisely what the merged PR ended up restructuring around.

If you're up for a follow-up, adding file + audio on top of the merged plumbing is now a small, self-contained change: the scoped resource download, streaming upload with size cap, attachment binding, and orphan cleanup all exist, so it's mostly extending the type switch and its tests. #5887 would be the issue to close with it, and I'll review it promptly. The durable inbound-event queue is a reasonable separate proposal too — I'd suggest an issue first so we can agree the design before you write the code, since that one is a real architectural change.

Sorry for the wasted rebasing effort here, and thanks for the care that went into it.