feat(langchain): add LC-024, ambiguous tool name

[bradAGI]

Ports the ambiguous-name check to LangChain. Claude SDK (CSDK-007), OpenAI (OAI-007), ADK (ADK-007), and MCP (MCP-003) all ship it; the newer packs had none.

The tool name sits directly beside the description in what the model sees, so it is half the selection signal — and a generic verb like process or handle spends that half on nothing. A LangChain agent is routinely handed a dozen or more tools at once, so a name that does not discriminate competes against every neighbor in the list — and each wrong pick spends an iteration against LC-102's max_iterations budget.

Same name_in list as CSDK-007, so behavior stays consistent across packs.

Verification — engine built at main:

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

Fire (tool named process): includes LC-024
Silent (same tool renamed summarize_invoice): LC-024 absent

A note on scope. I drafted a fifth rule in this batch for the Vercel AI SDK and dropped it after testing: ToolDef.Name is deliberately empty for vercel_ai_tool, because the SDK derives a tool's name from the key in the tools: { ... } record rather than from the tool({...}) call. The engine asserts this directly —

// internal/analysis/ts_vercel_tools_test.go
if tl.Name != "" {
    t.Errorf("Name: got %q, want empty (Vercel derives name from the tools-record key)", tl.Name)
}

so every name-based predicate (name_in, name_has_prefix) is structurally inert for that pack — it also blocks a Vercel idempotency rule, which is why the pack has none. Back-filling Name from the record key at discovery time would unblock both. Happy to open that engine PR if it'd be useful.

Paired engine PR follows, mirroring the rule into testdata/rules-fixture/ with fire/silent cases.

[jhumel-code]

Thanks @bradAGI, this is a clean port. LC-024 matches CSDK-007 exactly on the name_in list, severity, and confidence, which is what I want for a list that is now shared across five packs, and langchain_tool is a valid applies_to at scope: tool with name_in already in the schema, so nothing here needs a schema_version bump. The LC-102 cross reference checks out (that is the max_iterations rule), and LC-024 is the only free number left in the LC tool range given the other LangChain PRs in flight, so no collision to sort out.

Two follow-ups rather than blockers. LangChain.js tools do carry a name (buildTSLangChainTool reads the config object's name literal), so a language: typescript twin of this rule would work where the Vercel one structurally could not. And yes, please open the engine PR that back-fills ToolDef.Name from the Vercel tools-record key.

One nit: the last sentence of explanation is a single long unwrapped line, so please wrap it to match the pack. Also, your rules validate output reports 211 rules where main plus this one comes to 207, was that run against a tree carrying your other branches?

Before this reaches users it needs a rationale doc in trustabl-rulebook. That part is on us, and I am happy to pair on it. I will take this together with trustabl/agent-reliability-analyzer#176.