test(deepseek-web): pin the buffered streaming tool-call contract (#14628)

[gonisulaimann]

Why

#14628 reports that a streamed deepseek-web reply carrying DeepSeek's double-pipe DSML tool-call markup reached the client as visible content with finish_reason: "stop" - the tool never executed and nothing in the stream hinted at failure.

At the current tip the buffered tool path already routes the full reply through parseDeepSeekToolCalls(), which understands the DSML grammar (the #14208 lineage), so the defect as described no longer reproduces. But nothing pins that contract, and the v3.8.50 build shows exactly how the streaming and non-streaming shapes drift apart.

What

A new suite (tests/unit/deepseek-web-streaming-dsml-14628.test.ts) drives DeepSeekWebExecutor.execute() end-to-end with a stubbed upstream - auth, session, PoW and completion all answered from a scripted fetch; the PoW challenge is a self-consistent difficulty-1 pair so the real solver answers nonce 0 in one hash - and asserts:

• a double-pipe DSML block with two invokes (the multi-invoke shape from the issue), streamed across two ANSWER fragments, becomes two tool_calls deltas with finish_reason: "tool_calls", and no U+FF5C/DSML markup reaches the content deltas;
• the tool-free streaming path still emits plain content with finish_reason: "stop".

No production change: the suite exists to keep the contract from regressing the way it did between v3.8.50 and the #14208 fix.

Verification

check	result
new suite	2/2 green on the release tip + this test
adjacent suites (deepseek-web-autorefresh-401-response, deepseek-web-auth-semantics, web-tools-translation, deepseek-pow-slot-leak-13094)	30/30

Closes #14628 as verified-fixed-at-tip (with the regression guard the issue asked for).

---

⚠️ base-red inherited: #14547 — the failing checks (API Route Typecheck, Docs Gates, Unit fast-path shards) also fail on release/v3.8.51 tip; none touch this PR's scope. (PR #14693 fixes two of the stale-test failures; #14683 owns the cliproxy typecheck + env-doc pair.)

[diegosouzapw]

This is a clean, well-scoped regression guard — thanks for tracing #14628 back to the #14208
fix and pinning the contract instead of re-fixing something that's already resolved. Verified
locally: 2/2 pass against DeepSeekWebExecutor.execute() with a stubbed upstream, and the
double-pipe DSML → tool_calls / no-leak assertions both hold. Ready to merge.