fix(desktop): stop polling unavailable collaboration authority

[testikun]

Summary

Fixes #4522

Desktop now learns whether each Runtime Host exposes collaboration authority from the authenticated host.status boundary. The global turn-request inbox skips Owner Hosts that explicitly report no collaboration authority, while legacy/unknown Hosts are probed once and then remembered as unavailable when they return the expected unavailable result. Transient reconnect failures retain the existing retry behavior. Expected background operation_unavailable results are projected as an empty inbox so Electron does not log repeated rejected IPC handlers.

Implementation

• Added an optional collaborationAuthority capability to Runtime Host status/diagnostics and propagated it through Desktop target identities.
• Performed one bounded status observation when a Desktop candidate connects, then reused the capability during inbox polling.
• Retained learned unavailable state when a legacy identity omits the optional capability.
• Limited the empty-inbox fallback to the background poll path; session-scoped collaboration queries preserve their original failures and semantics.
• Kept collaboration grants and permission semantics unchanged; only polling/read projection handles unavailable authority.

Verification

• npm --workspace @maka/runtime-host run build
• npm --workspace @maka/runtime-host run typecheck
• npm --workspace @maka/desktop run build:test
• 118 focused Runtime Host protocol and Desktop collaboration/manager tests passed.
• npx biome check and npx biome lint passed for all changed files.
• Desktop main-process typecheck passed. Full Desktop typecheck remains blocked by pre-existing workspace errors in apps/desktop/src/preload/runtime-host-session-catalog.ts and unrelated @maka/ui type drift under the available Node/npm environment.

Platform limitations

Hosts built against an older compatibility epoch must complete the normal upgrade/reconnect path before collaborating with this Desktop build. Legacy Hosts on the current epoch that omit the optional capability remain compatible: Desktop probes them once and remembers an expected unavailable collaboration result until a fresh Host identity/status observation says otherwise.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex authored the implementation and regression tests.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Phoenix500526]

The capability-based direction looks sound. I found three merge-readiness items below; I am leaving this as comments only, not an approval or merge request.

[testikun]

Addressed in b325755 (rebased onto the latest apache/main):

• Advanced RUNTIME_HOST_COMPATIBILITY_EPOCH to 99 and documented the new host.status wire-shape rationale.
• Kept the empty-inbox fallback limited to the background query, requiring the exact collaboration.turn-request.query operation plus operation_unavailable; scoped session queries still rethrow.
• Added a polling/cache-boundary regression test proving an unknown legacy Host is queried once, caches authorityUnavailable=false, and is skipped on the next getPendingTurnRequests() poll.

Biome checks and the focused polling/cache tests pass locally. The full workspace build remains affected by pre-existing cross-package type drift under the available Node/npm environment.