Coalesce OpenCode fleet activity renewals without per-message subprocess reconciliation

[dataforxyz]

Problem

The lifecycle integration in #2 correctly renews only when the primary OpenCode manager receives a message from the exact owned worker. Each inbound message currently invokes the packaged fleet CLI, which starts a Node subprocess and reconciles worker units before renew. Bursty worker progress can therefore create avoidable subprocess/systemctl load.

The 60-second internal heartbeat is also fixed rather than sourced from orchestrator heartbeatSeconds.

Desired direction

• coalesce exact worker activity IDs over a short bounded window
• use a lightweight internal activity update path that acquires the worker-store lock but does not run full extension startup/reconciliation
• preserve exact manager ownership and stable-ID checks
• keep cleanup/adopt fencing intact
• source heartbeat cadence from orchestrator configuration or return it from the internal lifecycle call
• surface renewal failures in health/diagnostics instead of swallowing them silently

Acceptance evidence

• a burst of many messages from one worker results in one bounded activity mutation
• unrelated senders cannot renew owned workers
• manager sends and protocol acknowledgments do not count
• cleanup cannot stop a worker after a committed concurrent activity update
• subprocess/systemctl invocation counts are covered by tests

Follow-up from independent Fable review of #2 and dataforxyz/orcboss#4.