vault read: default to full file content instead of fragments

[iamclaude697]

Problem

vault read with a specific file path defaults to fragment retrieval (5 fragments of ~400 chars each) instead of returning the full file. This is surprising behavior — when a caller passes an explicit path, the intent is "give me this file," not "give me a semantic sample."

The only indication that content was truncated is a subtle tip line at the bottom of the response (Use view.file(path) for full content). LLM consumers in particular can easily treat the fragments as the complete file, leading to silent data loss in agentic workflows.

Current behavior

vault action: "read", path: "some/file.md"
→ returns 5 fragments (~2000 chars total from a ~5000 char file)
→ tip at bottom: "Use view.file(path) for full content"

Expected behavior

vault action: "read", path: "some/file.md"
→ returns complete file content (same as returnFullFile: true)

Proposal

Change the default for returnFullFile to true when a path is provided. Callers who want fragments can either:

• Pass returnFullFile: false explicitly, or
• Use vault fragments, which already exists as the dedicated fragment retrieval tool

The existing 2000-word warning ("This file contains N words. Consider using fragment retrieval...") already covers the large-file case, so the safety net is in place.

Alternative (minimum viable)

If changing the default is too broad, add an explicit truncation warning to the fragment response, e.g.:

⚠ Showing 5 of ~23 paragraphs. Pass returnFullFile: true for complete content.

The current tip line is too subtle for automated consumers.

Impact

• view file already returns full content with no limits
• vault combine already returns full content via getFile()
• vault read is the only read operation that silently fragments by default
• No other vault operations (copy, split, move, rename) are affected