v3.9.1 — Delete the safety net that was not there

A deletion-only release. 100 lines out of app/api/chat/route.js, no behaviour change, 701/701 tests green.

Before data_resource handles existed, a tool output too large to relay inline was truncated at VFB_TOOL_OUTPUT_TRUNCATE_CHARS and, past a total trigger, split into chunks for a summarisation pass. Four functions implemented it — truncateToolOutput, shouldCompressToolOutputs, buildToolOutputCompressionChunks, getRelayToolOutput — configured by five environment variables.

Resource handles made it unreachable. The threshold that diverts a large result into a resource sits in front of everything the compression path was for, so the four functions have referenced only each other for several releases, and getRelayToolOutput read an item.relayOutput field that no code in the repository writes.

The reason to remove it rather than leave it idle is that it was making a promise. A reader of route.js, or of a deployment's environment, would reasonably conclude that oversized outputs are still truncated as a second line of defence and would tune DATA_RESOURCE_INLINE_MAX_CHARS on that assumption. They are not. The resource threshold is the only thing standing between a large tool result and the prompt, and anything that survives it is sent whole. docs/tool-result-resource-strategy.md now states that single-mechanism guarantee explicitly.

These five variables are no longer read and can be deleted from any deployment that still sets them: VFB_TOOL_OUTPUT_TRUNCATE_CHARS, VFB_TOOL_OUTPUT_COMPRESSION_TOTAL_TRIGGER_CHARS, VFB_TOOL_OUTPUT_COMPRESSION_CHUNK_CHARS, VFB_TOOL_OUTPUT_COMPRESSION_MAX_INPUT_CHARS, VFB_DISABLE_TOOL_RESULT_COMPRESSION.

stringifyToolOutput is kept — it is live in the resource-storage decision.

Full Changelog: v3.9.0...v3.9.1