fix(dashboard): respond to manual heartbeat run as soon as run record exists

POST /api/agents/:id/runs previously awaited resolvedMonitor.executeHeartbeat
end-to-end before sending the response. For real provider runs that take
tens of seconds to minutes, Safari (and intermediate proxies) drop the
client socket and the dashboard surfaces "Failed to start heartbeat run:
load failed" — the run is actually in flight, but the toast suggests it
failed to start.

The route now kicks off executeHeartbeat in the background, polls briefly
for the active-run record (created synchronously inside executeHeartbeat
→ startRun), and returns 201 with that record. Synchronous failures of
executeHeartbeat are still surfaced to the client; background failures
are logged via runtimeLogger.child("heartbeat"). The 409 active-run
conflict contract is preserved.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.changeset/heartbeat-run-fire-and-return.md

@@ -0,0 +1,9 @@
+---
+"@runfusion/fusion": patch
+---
+
+Manual heartbeat runs (POST /api/agents/:id/runs) now respond as soon
+as the run record is created instead of blocking on the full
+executeHeartbeat call. Long-running heartbeats no longer cause the
+dashboard to surface "Failed to start heartbeat run: load failed" when
+the client socket times out before the run completes.