feat(openai_sdk): add OAI-029, TypeScript tool writes to the filesystem

[bradAGI]

OAI-006 covers the Python path-safety case; the TypeScript half was missing. Mirrors CSDK-012 — the TS half of the Claude SDK pair — including its coarse-signal caveat, stated in the explanation so the finding is honest about itself: it flags any filesystem write, not only unnormalized paths, because TS path-normalization analysis isn't wired yet. Confidence 0.5 to match.

In an SDK built around guardrails, the point worth making is that the guardrail story doesn't cover this. OAI-101 is about input guardrails on the agent — they screen what enters the conversation, not what a tool does with an argument once the model has produced it. A tool call that reaches execute() has already passed whatever guardrails were configured. Anyone reading this finding and thinking "we have guardrails" would be wrong, so the rule says so directly.

Tools here also typically run in the same server process as the request handler rather than a sandbox, so the write inherits the application's own filesystem permissions.

The fix names the stronger remedy for the common case: derive the filename server-side from an id rather than accepting a path from the model at all.

Verification — engine built at main:

$ trustabl rules validate .
OK: 85 rule pack(s), 207 rule(s) valid under rule schema version 14

Fire (writeFileSync(notePath, body) with notePath from the parameters schema): OAI-029, OAI-202
Silent (server-derived id, no model-supplied path): OAI-202

(OAI-202 is the pre-existing missing-CLAUDE.md repo rule.)

No new predicates, so no schema_version bump.

[jhumel-code]

Thanks @bradAGI, this is a clean one. Checked against the schema on main and it holds up: all nine required fields are present, openai_tool is a valid applies_to for scope: tool, has_write_call already exists as a predicate, and you are right that no schema_version bump is needed since nothing new lands on the engine side. OAI-029 is not claimed by any other open PR, and low / 0.5 matches CSDK-012, which is the right neighbor to anchor against. I also appreciate that the explanation states the coarse-signal caveat rather than hiding it, and the OAI-101 clarification is a genuinely useful thing to say in an SDK where people reach for guardrails as the answer to everything.

One property I would like written down, ideally in the rationale doc: because the match is just has_write_call: true, applying the fix does not clear the finding. A tool that resolves the path and confines it under a root still writes, so it still fires. CSDK-012 has the same shape, so this is not new, but two of them doubles the findings a user cannot clear. Not blocking.

A new rule also needs a rationale doc in trustabl-rulebook before it ships. We can handle that or pair on it, it is not on you. This should land together with trustabl/agent-reliability-analyzer#173 so rules-sync stays green.