feat(put_page): add --file param to bypass Windows pipe buffer limitation

[ecat2010]

Problem

On Windows, the default pipe buffer size is limited (~45KB). Passing large content to gbrain put_page via stdin/pipe silently truncates or fails.

Solution

Add a file parameter to put_page operation. When provided, the handler reads content directly from the file, completely bypassing the pipe buffer limitation.

Changes

• content param: required: false (was true, now optional)
• Add file param to put_page operation params
• Handler: if p.file is set, read file content via fs.readFile
• Handler: throw invalid_request if neither content nor file is provided

Backward Compatibility

• Existing clients that pass content only: still work unchanged
• capture --file CLI: already works (uses content after reading file locally)
• put_page with file param: new feature for MCP and direct API callers

Related

Fixes #1363

---

• content param backward compatible
• file param reads file correctly
• Error when neither param is provided

[garrytan]

Closing as redundant with the already-shipped gbrain capture --file PATH --slug SLUG (v0.39.3.0). Capture is the canonical file-as-input ingestion path on every platform — it reads files via readFileSync(path) (Buffer-first, no encoding), scans the first 8KB for NUL bytes to refuse binary content, decodes to UTF-8 only after the safety check, and adds provenance write-through. The intent behind this PR is real, especially for Windows users hitting pipe-buffer limits.

The v0.41.4.0 wave (#1377) lands a doc improvement that points Windows / pipe-buffer users at capture from gbrain put_page --help, so the discoverability gap closes even though the code change itself doesn't ship. Your contributor credit is in the wave's commit body.

Historical context for posterity: the original diff inserted the new handler block into get_page's handler instead of put_page's — every read in the system would have thrown invalid_request. The v0.41.4.0 wave's R1 + R2 regression tests pin both behaviors permanently.