fix(ai): cap native inline file size at 50 MB to prevent V8 OOM

[xxiaoxiong]

TL;DR

Cap the size of files inlined as base64 data: URLs at 50 MB, enforced before the read to prevent V8 heap exhaustion and app crash (SIGTRAP) when users attach ~238 MB PDFs.

Problem

fileProcessor.ts inlined every file as base64 without any size check. Base64 inflates a file by ~4/3; a 238 MB PDF becomes ~317 MB of base64, and with JSON.stringify overhead the main-process V8 heap (~2 GB on an 8 GB machine) is exhausted, leading to SIGTRAP and whole-app exits. This is #19706.

Fix

Two pre-read size guards:

• fileEntryId branch: FileManager.getMetadata(size) called before read(encoding: base64) — prevents allocating the inflated base64 buffer for oversized files.
• file:// URL branch: fs.stat(absPath) called before fsRead(encoding: base64) — same guard. stat follows symlinks, so symlink squatting cannot bypass the cap.

On any error (missing entry, permission denied), size is treated as Infinity so the part is degraded to a note, matching the existing failure path.

Test coverage

Updated fileProcessor.test.ts to mock FileManager.getMetadata and verify:

• Normal-sized files pass through unchanged
• Over-cap files return null without calling read
• Missing/unreadable entries degrade to null (existing behaviour preserved)

References

• Closes [Bug]: App crash (main-process V8 OOM / SIGTRAP) when sending a ~238MB PDF to gemini-3.7-flash — no size cap on native inline attachments #19706
• 50 MB matches the Gemini inline PDF limit (no larger file can be sent natively anyway)
• A NATIVE_INLINE_FILE_CAP_BYTES constant is exported for future per-provider override (e.g. DashScope qwen-vl ≤ 10 MB raw in attachmentRouting.ts)