fix: emit [] not null for empty tool output collections

[bobby-smedley]

🎯 What does this PR do?

Fixes an intermittent error where a tool could fail with:

validating tool output: ... /properties/results: has type "null", want "array"

What was wrong: chip generates each tool's schema from its Go types. An earlier fix cleaned those schemas up so every list/map is described as a plain "array"/"object" instead of "a list or nothing" — that stopped some clients (e.g. Cowork) from mis-sending list arguments. The catch: the same cleanup also applied to the output schemas, which now disallow "nothing" (null). But in Go, a list that was never filled in becomes null when converted to JSON. So whenever a tool returned no results (an empty search, or an early error like "asset not found"), it emitted null and failed its own output check. It looked random because it only happened on the empty path — any response with results worked fine.

The fix: rather than loosen the schema again (which would undo the input fix), we make the data match the schema. Right before a tool's response leaves the server, any unset list becomes an empty list [] and any unset map becomes {}. This is done once, in one shared place, so it covers every tool — current and future — with no per-tool changes.

Safety: the schema and the input-side fix are untouched — we only change the outgoing data. Empty collections still satisfy omitempty, so optional fields are still omitted, and the schema clients see is unchanged. Adds unit and end-to-end tests, including one that confirms the bug returns if the fix is removed.

✅ Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation (if needed). — N/A, no docs affected
• My commit messages follow the Conventional Commits standard.