Bug: tool registration accepts control-character names, megabyte descriptions, and duplicate names — ambiguity reaches the wire instead of failing loud at load

[FermiHart]

Packages: @deepseek-ai/dsh-tools (register()), core/tools schema.ts, system-prompt assembly invariant
Severity: low-medium · Confidence: high — hostile names accepted verbatim through the real registration path

Problem

Tool registration validates output shape, schema, timeout, and reserved names — but not identity hygiene. Accepted verbatim (proven through the real plugins):

• "read\nfile", "read\u0000file", "<unlisted-tools>-ish", " read file "
• a 4096-character name
• a 1,000,000-byte description

These flow unchanged into provider requests (serialize.ts maps tool.name/description as-is). Additionally, two providers registering the same tool name both reach assembly — duplicates are pinned as intended by the stable-sort test.

Consequences, per the repo's own conventions:

1. Misconfiguration should fail loud at load — a malformed tool name is self-contained and checkable at register(), yet it instead surfaces as a provider-side HTTP 400 mid-session.
2. Megabyte descriptions bloat/KV-cache-bust every subsequent request.
3. A duplicate name puts two schemas under one model-visible identity while the executor resolves exactly one definition — description-level impersonation of another capability, reachable from any third-party bundle or preset.

No shipped producer emits such values today; exposure is the third-party plugin surface this repo explicitly invites.

Fix direction

Validate at register(): name matches a conservative grammar (^[a-zA-Z][a-zA-Z0-9_-]{0,63}$), description byte-capped, duplicate key rejected loudly. All three checks are load-time-self-contained and align with the fail-loud rule.