feat: attach the offered tool definitions to every generation

[milanagm]

Closes #23.
LFE-16207

Change

A trace recorded which tools the model called — tool_calls on the generation output, Tool: <name> spans — but not which tools it was offered, so it could not distinguish "not offered" from "not chosen", and the Langfuse playground had no tools to replay a generation with.

Each generation input now carries the definitions of the tools in the request as tools on its first message, which is where the Langfuse UI reads them and dedupes by name.

The set is pi's active tools, which is narrower than the registry. Measured on pi 0.84.2 with a probe on before_provider_request, reading event.payload (the real wire request):

registry (getAllTools):  read, bash, powershell, edit, write, grep, find, ls   ← 8
active  (getActiveTools): read, bash, edit, write                              ← 4
wire    (payload.tools):  read, bash, edit, write                              ← 4

So getAllTools() alone would over-report by four tools. The active names drive both membership and order, since that is what goes on the wire; the registry only supplies each schema. Both accessors are optional-chained and the helper never throws, so a pi without them degrades to no tools.

The generation input is now a ChatML message array

This is the part that makes the feature actually visible, and it is a fix in its own right.

The generation input was a bare message object. Langfuse normalizes generation input with ChatMlArraySchema, and its single-message fallback (langfuse#16565) only accepts a message carrying content or tool_calls. pi's generations after a tool call are {role: "tool", tool_results: [...]}, which match neither — so they fail to parse, fall back to the raw JSON view, and drop the tool definitions entirely.

Verified by replaying the real captured payloads of a three-generation turn through Langfuse's own normalizer at current main, plus the Tools-section logic from useChatMLParser:

generation	main	#26	this PR
0 — role: "user"	chat ✔, no tools	chat ✔, tools ✔	chat ✔, tools ✔
1 — role: "tool"	chat ✘, raw JSON	chat ✘, raw JSON	chat ✔, tools ✔
2 — role: "tool"	chat ✘, raw JSON	chat ✘, raw JSON	chat ✔, tools ✔

Wrapping the message in a one-element array fixes all three, and keeps the input composable with any later change that turns it into a real message list.

Tests

• pnpm typecheck clean; pnpm test 67 of 67 passed, up from 62 on main.
• Five tests: the two helpers (first-message attach with no mutation, pass-through when there is nothing to attach; active-only narrowing with order and ChatML-field projection; graceful degradation on a pi without the accessors or with throwing ones), plus one integration test that reads the exported generation inputs of a real sandbox run and asserts each is a message array carrying ["read", "bash", "edit", "write"] with their schemas.
• Reverting only the array wrapping, keeping everything else, turns the integration test red with `generation 0 input must be an array of messages

[hassiebp]

LGTM after resolved conflicts 👍

[milanagm]

@hassiebp resolved