Fix Word export packaging for scrybe-docx

[hartsock]

Summary

• Resolve scrybe-docx from SCRYBE_DOCX_BIN, a bundled sibling executable, PATH, and the default ~/venv/bin toolkit install location in both the desktop app and MCP export tool.
• Install the local Mermaid Python binding and docx exporter from just install / just editable, and include scrybe-plugin-docx in the scrybe.ai metapackage.
• Build and publish scrybe-plugin-docx in the release workflow, add a tracked pre-push parity hook, and add packaging drift tests so the exporter does not fall out of the install/release path again.

Validation

• cargo test -p scrybe-mcp-server
• cargo test -p scrybe-app
• just check
• just test (rerun outside the sandbox because CLI RPC tests bind local Unix sockets)
• npm ci && npm run build in scrybe-app
• /Users/shartsock/venv/bin/python -m pytest scrybe-plugin-docx/tests
• /Users/shartsock/venv/bin/python -m build --outdir /private/tmp/scrybe-docx-dist in scrybe-plugin-docx

Risk

risk:high because this touches release workflow packaging, local hook behavior, and metapackage dependencies.

Notes

This makes the current Scrybe Python toolkit and local development install paths include and discover the Word exporter, and it gives the desktop app a bundled-sibling lookup path for future installer bundling. A fully self-contained Tauri installer that embeds a Python docx exporter runtime is still a larger packaging follow-up.

Fixes #106

Agent

Codex (MacBook, GPT-5)