Worker should publish which sync adapters it actually registered

Follow-up from #160.

supportsOutboundSync() (packages/outpost/shared/src/sync/capabilities.ts) gates force-sync so the dashboard can't enqueue TRACKER_SYNC jobs for a plugin the worker has no adapter for — those jobs return Plugin "<name>" is not registered, which worker.ts handleFailure retries to maxAttempts and then dead-letters.

The list is static, but registration is additionally conditional on env: initializeSyncEngine() only registers Linear when both LINEAR_API_KEY and LINEAR_TEAM_ID are set. So a deployment missing either has no Linear adapter while supportsOutboundSync('linear') still returns true — the DLQ flood the gate closes by design stays reachable by misconfiguration.

The web app can't just read those env vars: web and worker are separate deployments and their env can differ, so checking locally would be a guess that's wrong in exactly the case that matters.

The real fix is the worker publishing what it actually registered — a SystemConfig row written at boot, or exposing it on the health endpoint. That makes this a natural companion to the /health work in #138, which is already about the worker reporting its own state.

Until then the limitation is recorded in the module doc rather than papered over.

Read packages/outpost/shared/src/sync/capabilities.ts, worker.ts, and the initializeSyncEngine() path, then review the related worker health work in #138. Decide how the worker should publish its actually registered adapters, and consider the issue done when the web app can use that worker-owned state to avoid enqueueing unsupported sync jobs.