fix(skills): stop retrying offline desktop recovery - #2158

Summary

• classify trusted BaaS NO_ACTIVE_DEVICES responses as an explicit Desktop offline state
• stop and release the current Desktop recovery task while the device is offline, while preserving retry/backoff for transport and 5xx failures
• filter recovery sweeps by Bot lifecycle status and emit one aggregate sweep record
• wake the existing durable recovery flow after a confirmed OFFLINE -> ACTIVE transition
• persist the finalized recovery semantics in the Desktop Skill spec, decision ledger, module docs, and Issue [Desktop Skills 验收] G1–G4 跨仓集成、预发 Postman 与实机统一验收 #2105 acceptance plan

Closes the I-04 implementation gap tracked by #2105.

Contract and compatibility

• Public HTTP/DTO shape is unchanged. DESKTOP_DEVICE_OFFLINE is an additive value of the existing string RuntimeProjectionIssue.code field.
• retryable=true still means a future projection may recover; it no longer implicitly instructs the current queue task to retry.
• Existing callers may continue handling the result as PENDING. Frontends may optionally show a device-offline hint.
• No Gateway OpenAPI regeneration, database migration, feature flag, outbox, or task-queue infrastructure change.
• OCB has no functional code change; integration requires only a later ocb-public gitlink bump.

Structural analysis

• Contract changed: yes, internal BaaS Service error contract and Desktop recovery continuation semantics.
• Contract type: Service API error hierarchy plus internal recovery policy; public REST schema unchanged.
• Consumers: BaasConnInfoBuilder, filesystem Runtime projection, Desktop Skill Recovery, Desktop health reconciliation, SkillSymlinkListener.
• Implementations: Community BaasService; no Corp override.
• Compatibility: additive subclasses preserve BaasServiceError catches; non-Desktop BaaS Bots retain the generic runtime-unavailable code.
• Migration/deprecation: none.
• Waiver: none.

Validation

• Backend affected + architecture gates: 467 passed
• Backend full suite: 18,539 passed, 60 skipped
• OCB Corp compatibility suite against this Avernet head: 185 passed
• Python SAST local block scan: passed
• Ruff on every changed Python file: passed
• Standards review: no remaining P0-P2
• Spec review: no remaining P0-P2

Deployment acceptance

Deployment and live validation remain separate. Follow Issue #2105 I-04 to prove old offline tasks drain, recovery traffic/log storms stop, and OpenClaw/Hermes reconnect without a second user SkillSet operation.