feat(openai_sdk): add OAI-027, OAI-028 TypeScript description quality rules

[bradAGI]

The TypeScript counterpart to OAI-025/026 (#87). OAI-022 only checks that a description exists, so a tool described "TODO: describe this tool." or "Gets data." passes today — while sitting in exactly the state OAI-022 exists to prevent. OAI-022's own text calls the description "the model's primary routing signal alongside the tool name," which is precisely why a placeholder in that slot matters.

Two points, both aimed at mitigations people assume already cover this:

• The Zod parameters schema doesn't compensate. It constrains the shape of the arguments once the model has decided to call this tool, never whether that decision was right. A placeholder description yields a well-formed call to the wrong tool — validation passes, the run is still wrong.
• With handoffs the reach is wider than one bad call. An agent picks between its own tools and its peers' from these strings, so the stub can route the conversation to the wrong agent rather than merely the wrong function.

OAI-028 adds the cost that's hardest to trace: each mis-selection spends a turn against the agent's max-turns budget, and nothing in a trace attributes the wasted turn to the description that caused it — the run just looks slow or confused.

Verification — engine built at main:

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

Fire (one tool({...}) described "TODO: describe this tool.", one "Gets data."): OAI-027, OAI-028, OAI-202
Silent (full description naming when to prefer the neighboring tool): OAI-202

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

OAI-028 pairs description_length_lt: 40 with has_docstring: true so it doesn't double-report against OAI-022 on an empty description, same as CSDK-018.

No new predicates, so no schema_version bump.

Merge note: this and #87 both append to openai_sdk/tool_definition.yaml, so whichever lands second needs a trivial rebase — the rule blocks are independent and the resolution is "keep both." Happy to rebase on request.

[jhumel-code]

Thanks @bradAGI. Checked this against main and it is clean. OAI-027 and OAI-028 are unclaimed IDs, openai_tool is a valid applies_to at scope: tool, language: typescript is stated explicitly as it must be for a TS rule, and every required field is present with no stray keys for the closed schema to reject. Both has_description_text and description_length_lt already exist in the engine at schema 14, so you are right that no schema_version bump belongs here. Severity and confidence line up exactly with CSDK-017 and CSDK-018, which is the precedent I would have pointed you at, and pairing has_docstring: true with the length check keeps this off OAI-022's territory.

The engine half in trustabl/trustabl#170 mirrors this file byte for byte and carries fire and silent cases for both rules, so the pair is complete and neither should land alone.

One note rather than a request: the needles are plain substrings, so a genuine tool described as adding a todo item, or one that fills placeholder values in a template, will fire OAI-027. That is inherited from CSDK-017 and not a reason to hold this up, but it is worth knowing when we see the first report.

New rules also need a rationale doc in trustabl-rulebook before they ship. That part is ours, and I can write it or pair with you on it.