xbbg 1.4.9

Fixed

• xbbg-mcp no longer stops silently when stdin misbehaves, and the Windows MCPB launcher stays out of the byte stream (#348). On one Windows host the v1.4.6 server answered initialize and exited a moment later with status 0 and nothing on stderr: tokio::io::stdin() reports any zero-byte read as end-of-input and turns read errors into a bare "connection closed", and no log subscriber was installed, so nothing recorded why. The server now reads stdin on its own thread -- a zero-byte read on a pipe whose writer is still connected (PeekNamedPipe) is retried instead of ending the session, a failed read is reported on stderr, and the process states why it stops (xbbg-mcp: stdin closed; shutting down, or the abnormal quit reason). It also installs the workspace stderr logger, so RUST_LOG works and rmcp/engine warnings reach the host's server log. The Windows launcher (xbbg-mcp.ps1) ran xbbg-mcp.exe as a PowerShell native command, which lets Windows PowerShell 5.1 sit between the MCP host and the server -- re-encoding stdout through the console code page and, under the script's $ErrorActionPreference = "Stop", terminating the child on its first stderr line. It now starts the binary with inherited standard handles and propagates its exit status, the Windows equivalent of the POSIX launcher's exec. The reported machine state did not reproduce on Windows 11 through Claude Desktop's own client library, a Node parent, a console, or a bare pipe, with either the shipped v1.4.6 binary or this build; the fix therefore closes every path by which stdin could end the process without a message rather than a single guessed cause.
• The Windows MCPB launcher checks the Bloomberg runtime it picks (#348). It accepted any directory holding blpapi3_64.dll or blpapi3_32.dll, so pointing XBBG_MCP_LIB_DIR at a Terminal's C:\blp\DAPI passed and the 64-bit binary then died in the loader with STATUS_ENTRYPOINT_NOT_FOUND and no output. It now requires blpapi3_64.dll, compares its file version with the Bloomberg API version the release was built against (scripts/package_xbbg_mcpb.py --blpapi-sdk-version, supplied by the release workflow), skips older runtimes with a message naming the version found, searches PATH as well (the Windows convention; a Terminal install puts C:\blp\DAPI there) before falling back to the Python blpapi package, and translates the loader statuses STATUS_DLL_NOT_FOUND, STATUS_ENTRYPOINT_NOT_FOUND, and STATUS_INVALID_IMAGE_FORMAT into one-line explanations.
• The MCPB manifest.json lists all nine tools (#348). check_entitlements was missing from the manifest's tools array and from scripts/xbbg_mcp_smoke.py's expected set even though the server advertised it.
• v1.4.7 and v1.4.8 shipped no PyPI, npm, or MCP assets. Both tags were cut, and their Rust crates published, without the PyPI and npm publish workflows being dispatched, so v1.4.6 stayed the newest installable release everywhere but crates.io. This release publishes every surface.

Full Changelog: v1.4.8...v1.4.9