Fix frontend extension session state and tool routes

[sunilkumarvalmiki]

Summary

Fixes the two open frontend-extension regressions around session state and app-facing tool routes.

Fixes #8425
Fixes #8426

What changed

• persist frontend extension configs alongside ExtensionManager-backed configs
• include frontend tools in Agent::list_tools() instead of only appending them during prompt preparation
• remove frontend tools cleanly when their extension is removed
• reject frontend tools in /agent/call_tool with a clear 424 Failed Dependency response instead of a generic 500
• add regression coverage for frontend extension persistence, listing, removal, and route behavior
• regenerate the desktop API client after the route response changes

Root cause

Frontend extensions were being flattened into in-memory tool state, but not tracked as extension configs.
That meant session persistence serialized only backend-managed extensions, /agent/tools missed frontend tools, and /agent/call_tool bypassed the agent-level frontend check and fell through to a backend-only dispatch path.

Behavioral impact

After this change:

• /sessions/{id}/extensions includes frontend extensions added through /agent/add_extension
• /agent/tools exposes frontend tools for the session
• /agent/call_tool fails explicitly for frontend tools with a client-facing explanation instead of a 500

Validation

• cargo build
• cargo test -p goose --test agent
• cargo test -p goose-server
• just generate-openapi
• cargo clippy --all-targets -- -D warnings

Live repro after fix

Using a local goosed instance with a frontend-e2e extension that provides frontend__echo:

• /sessions/{id}/extensions included frontend-e2e
• /agent/tools included frontend__echo
• /agent/call_tool returned:

{"message":"Tool 'frontend__echo' is provided by the frontend and must be executed by the frontend host"}

with HTTP/2 424.