[Feature]: Server-side stored scripts for code execution so long workflows need not be re-sent inline on every call

[algis-dumbris]

Problem / motivation

Today every code_execution invocation ships the entire script inline in the tool-call arguments.
For an agent that re-runs the same orchestration workflow, that cost recurs on every single call: a
19,341-byte workflow script costs roughly 4.8k tokens per run, paid again on each retry, each
parameter tweak, and each loop iteration — before any tool output comes back.

The existing ergonomic escape hatch is client-side only. mcpproxy code exec --file workflow.js --input-file data.json (shipped in PR #138, from the request in #136) reads the file on the CLI
side and still posts the full body to the daemon. An MCP client has no equivalent at all: it cannot
reference a script by name, only inline it.

Proposed solution

Let the daemon store named scripts and let callers invoke them by reference:

• Storage: a scripts/ directory under the mcpproxy config dir, and/or a code_scripts config map
  of name → path. File-backed keeps it reviewable and diffable, and avoids adding a mutation API
  as a first step.
• Invocation: code_execution accepts script: "<name>" as an alternative to code, with input
  unchanged. CLI equivalent: mcpproxy code exec --script <name> --input '{...}'.
• Discovery: mcpproxy code scripts list and, for MCP clients, either a list_scripts tool or the
  script names surfaced in the code_execution tool description.
• Reload: pick scripts up via the existing config file-watcher, so editing a script does not need a
  daemon restart.
• Explicitly out of scope for v1: a write/upload API. Read-only, filesystem-sourced scripts sidestep
  the obvious "agent writes arbitrary persistent code into the proxy" concern.

Per-run token cost drops from ~4.8k to a name plus its input.

Which edition?

Both.

Alternatives considered

• Keep using --file. Client-side only; does not reduce what is sent over the wire, and is
  unavailable to MCP clients, which is where the token cost is actually paid.
• Prompt-caching the inline script. Client-side, provider-specific, and does nothing for the
  CLI/REST paths.
• Upstream MCP prompts (proposed in open [Feature]: Aggregate/proxy upstream servers' MCP prompts through prompts/list #972) are a nearby "named reusable server-side
  artifact" idea but address prompt text, not executable orchestration.

Notes

Discussion #206 tracks other code-execution implementations and may be relevant prior art.

• I searched existing issues and discussions and did not find a duplicate