activity: an upstream returning isError:true is recorded as status=success, so real tool failures never surface as errors

[Dumbris]

Noticed while doing live QA of the tray glance section (#930), but this is a core-side classification issue and predates that PR.

What happens

When an upstream MCP server returns a result with isError: true — a bad timezone, an unknown tool name, a server-side validation failure — the activity record is stored with status=success. Only mcpproxy's own pre-dispatch argument validation produces status=error.

Why it matters

Every consumer of activity status under-reports failures:

• The tray glance histogram's "Errors" series and the red ⊗ row markers miss them.
• The 24h error counts in the usage timeline are correspondingly low.
• Anyone debugging "why did my tool call not work" sees a green success row for a call that failed.

Reproduced during QA: calls to time:get_current_time with an invalid timezone and to a nonexistent tool both landed as status=success, while an argument-shape violation caught before dispatch landed as status=error.

Suggested fix

Inspect the MCP result's isError flag when recording the activity entry and classify accordingly. Worth deciding explicitly whether an upstream-reported error should be a distinct status from a proxy-side error — they are different things to debug, and the UI could usefully tell them apart.