fix(llm): stream structured fallback and expose fetch error cause

[cloud5418]

Problem

Long-output structured invocations (e.g. `novel.volume.skeleton@v2`, volume strategy planning, long chapter macro plans) failed with:

```
[STRUCTURED_OUTPUT:transport_error] [novel.volume.skeleton@v2.fallback] Request timed out after 200000ms.
```

Root cause: third-party OpenAI-compatible aggregator proxies (commonly used to serve gpt-5.x reasoning models in China) cut idle non-stream connections after ~125s. The reasoning + JSON generation regularly exceeds that window for prompts that produce >5KB output, so the request times out without a single response byte and the application can only report a bare `fetch failed` after its own fallback timeout fires.

A separate but related issue: when the underlying `fetch failed` did have a useful Node `error.cause` (e.g. `code=ENOTFOUND`, `UND_ERR_SOCKET`, `ECONNRESET`), the existing classifier dropped it and the user only saw `[STRUCTURED_OUTPUT:transport_error] fetch failed`, making diagnosis impossible.

Fix

Stream the direct-transport fallback

`invokeStructuredPromptJsonViaDirectOpenAICompatible` (the prompt_json fallback path that runs raw `fetch` without LangChain) now:

• sends `stream: true` in the request body
• parses Server-Sent Events into the same string the existing parser consumes
• falls back to JSON parsing when the upstream ignores `stream: true` (i.e., the response `content-type` is not `text/event-stream`/`application/x-ndjson`)

Because chunks keep the socket alive, the 125s idle cap no longer trips on long generations.

Expose `error.cause`

• New `describeNetworkErrorCause` walks up to 6 levels of `error.cause` to extract undici/Node fields (`code`/`errno`/`syscall`/`hostname`/`address`/`port`).
• New `enrichErrorMessageWithCause` appends `(cause: code=…)` to the message when one is found and not already present.
• `wrapStructuredInvokeError` uses `enrichErrorMessageWithCause` instead of bare `error.message` and forwards the original error as the `cause` of `StructuredOutputError`.
• `summarizeStructuredOutputFailure` now appends the parsed cause (and a "check upstream / proxy" hint) when category is `transport_error`.

Verification

End-to-end against the production-style aggregator (sub2api → gpt-5.4):

Scenario	Result
Non-stream 10-volume skeleton POST	socket cut at 125s, 0 bytes (curl 56)
Streamed 10-volume skeleton POST (this change)	154s, 1.0MB SSE, finish_reason=stop, 10 volumes parsed
`invokeStructuredLlmDetailed` full strategy seq	strategy[0/1] aborted at ~43s as before, fallback (this change) completes in 137.6s with full 10-volume JSON; previous code hit 200s fallback timeout

`pnpm --filter @ai-novel/server typecheck` clean.

Relevant unit tests pass (these were the ones touching the transport fallback path):

• `tests/storyMacroFallback.test.js`
• `tests/directorBookContractFallback.test.js`
• `tests/directorCandidateFallback.test.js`
• `tests/directorRecoverySampleAudit.test.js`

Compatibility / Risk

• Adding `stream: true` is OpenAI-protocol-standard; aggregators tested (sub2api, ccp) accept it. Providers that ignore the flag still return JSON and the existing JSON path handles them.
• SSE parsing is contained to the fallback transport. The primary LangChain `ChatOpenAI` invocation is unchanged.
• The `cause` propagation is additive — message strings are only extended, never replaced. The existing classifier still returns `transport_error` for the same inputs.

Why now

Reported failures on `novel.volume.skeleton@v2` and earlier `auto-director` rhythm/chapter-split stages in production. With this change, long-running structured invocations against proxied gpt-5.x reasoning models can complete instead of timing out at the proxy idle limit.