fix: keep "Building…" visible during tool calls + recover from empty responses

[DoyleDev]

Summary

Two symptoms users hit during agentic tool loops, no version bump — meant to land on top of v1.4.1 (rebuild + re-release).

1. The brick indicator disappeared during tool execution. `addMessageEl("tool-call", "Calling tool: X")` removes the indicator. For slow stdio MCP calls (3-10s), users saw "Calling tool:" → static silence → result, and assumed Mason was stuck. Now `showThinking()` fires right after the "Calling tool:" line, so the bricks stay visible while the tool runs.

2. Opus 4.7 sometimes returned an empty text response after a tool loop. Extended-thinking models count thinking tokens against `max_tokens`; with the budget at 4096 and a complex multi-step request, the model burned the budget thinking and produced no visible output. Mason rendered an empty bubble and exited the loop — looked dead.

Fixes:

• Detect empty text response, surface a clear in-chat error ("Model returned an empty response — likely hit its token budget. Try sending 'continue' to resume…"). Message branches on whether the conversation had prior tool calls.
• Bump `max_tokens` from 4096 → 16384 for chat completions and `max_output_tokens` 4096 → 16384 for Responses API. Gives Opus 4.7 (and others with extended thinking) breathing room. Also reduces tool-call argument truncation (the earlier sanitize-arguments fix dealt with the symptom; this raises the ceiling so it's less likely to happen).

Lands on top of v1.4.1 — keeping the version at 1.4.1 per user request; user will rebuild and re-release.

Test plan

• Multi-step Opus 4.7 conversation that calls 5+ tools in sequence — bricks visible the whole time, no empty-response stall.
• Sonnet conversation with a long stdio MCP call — bricks visible during the wait.
• Intentionally low-budget request (e.g. paste a huge file into the chat) — if the model returns empty, user sees the error hint, not silence.

This pull request and its description were written by Isaac.