fix(pi): make ftown tool schemas provider-compatible

[fkesheh]

Root cause

The multi-operation Pi tools registered root-level anyOf schemas. The existing tests used a permissive registerTool mock, so they never exercised provider schema validation. OpenAI requires function parameters to have a root type: "object" and rejects root combinators.

Fix

• flatten all five ftown tool schemas to provider-compatible object roots
• use typed string enums for operation and other enum fields
• preserve operation-specific required fields with execution-time validation before any bridge request
• flatten the interval/cron schedule schema for broader provider compatibility
• bump ftown-bridge to 0.19.9
• add the proof-based investigation and update presubmit evidence

Verification

• reproduced the original 0.19.8 failure with Pi 0.83.0 and OpenAI gpt-4.1-mini
• ran the corrected extension through native Pi with all five ftown tools enabled: OK
• focused extension tests: 14 passed
• full bridge suite: 571 passed, 0 failed
• TypeScript build passed
• package dry run produced ftown-bridge-0.19.9.tgz

The regression test now rejects any ftown tool without a root object schema or with a forbidden root combinator.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ftown	Ready	Preview	Aug 9, 2026 9:07pm

[fkesheh]

Provider follow-up: the reported session was likely using DeepSeek rather than OpenAI. DeepSeek exposes an OpenAI-compatible tool/function schema boundary, which explains the same validation error. I reran the corrected extension through native Pi 0.83.0 with deepseek/deepseek-v4-flash and all five ftown tools enabled; it returned OK with exit code 0.