feat: add document creation/writing capability

[avoidwork]

Summary

Add tools to create and write document files (DOCX, XLSX, PPTX, PDF) — the write counterpart to the existing read-only document parsers.

Motivation

The agent can read DOCX, XLSX, PPTX, and PDF files, but has no way to create or write them. In office workflows, this is a critical gap: drafting a report, building a spreadsheet, creating a slide deck, or generating a PDF summary all require write capability. Currently the agent must fall back to shell commands invoking pandoc, python-docx, or similar — which is fragile and requires the user to have those tools installed. A native skill would provide a reliable, consistent interface for document creation.

Proposed Solution

Create a create-document skill that accepts structured content (markdown, tables, slide outlines) and outputs the requested file format. The skill would:

• Accept content in a canonical format (e.g., markdown for DOCX, tabular data for XLSX, slide JSON for PPTX)
• Use appropriate libraries (python-docx, openpyxl, python-pptx, weasyprint or similar) to generate the output file
• Return the path to the generated file
• Support common output formats: DOCX, XLSX, PPTX, PDF

Alternatives Considered

• Relying on shell invocations of pandoc/python libraries: fragile, requires user-installed dependencies, inconsistent error handling.
• Exporting via a web service: adds infrastructure complexity for a local-first tool.

OpenSpec Note

This project uses OpenSpec for feature development. If this request is approved, I will:

1. Run /opsx:propose to generate a full proposal with specs and tasks
2. Iterate on the design before any code is written
3. Follow the task-driven implementation workflow

Additional Context

This is the flip side of the existing document reading tools. The skill should mirror the read tools' output structure where possible for consistency.

Audit Findings (for Issue #778)

• src/tools/fileExtract/docx.js — Existing DOCX read tool (docxExtract). A write tool would mirror this structure: accept content input, use a library like docx.js or python-docx, return file path.
• src/tools/fileExtract/xlsx.js — Existing XLSX read tool (xlsxExtract). Write counterpart would need openpyxl or xlsxwriter for formula support.
• src/tools/fileExtract/pptx.js — Existing PPTX read tool (pptxExtract). Write counterpart would use python-pptx or pptxgenjs.
• src/tools/fileExtract/pdf.js — Existing PDF read tool (pdfExtract). Write counterpart would need a PDF generation library (pdfkit, puppeteer, or weasyprint).
• src/tools/fileExtract/formatValidator.js — Shared validation utility; write tools could reuse this for input validation.
• src/tools/fileExtract/zipExtractor.js — Shared ZIP extraction for .docx/.xlsx/.pptx (all ZIP-based); write tools would need the inverse (ZIP packing).
• src/tools/index.js — Tools are registered here with TOOL_PERMISSIONS and TOOL_CLASSIFICATIONS maps. New write tools would need entries in both maps.
• src/tools/fileExtract/ — Directory is the natural home for new write tools (e.g., createDocx.js, createXlsx.js, createPptx.js, createPdf.js).
• Dependency note — Write tools will require new npm packages (e.g., docx, xlsx, pptxgenjs, pdfkit) or a sandboxed Python environment. This is a key implementation decision point.