fix(server): offload cron job listing from dashboard event loop

[PINKIIILQWQ]

What does this PR do?

GET /api/cron/jobs is an async dashboard endpoint, but it performs synchronous profile enumeration and per-profile cron file I/O inline. If those filesystem operations become slow, the dashboard event loop is blocked and other HTTP/WS traffic can be starved during Desktop boot.

This PR offloads only the synchronous cron/profile work to asyncio.to_thread(...):

• _cron_profile_dicts()
• _call_cron_for_profile(...)

The handler shape, response format, profile parameter behavior, and error handling are preserved.

Why?

This is a small defensive fix for the broader issue tracked in #45072.

It complements #44930: that PR removes a concrete slow profile alias scan, while this PR prevents the cron jobs endpoint from freezing the dashboard event loop if synchronous profile/cron I/O becomes slow again.

What this does not change

• No Desktop renderer changes
• No gateway lifecycle changes
• No MCP startup changes
• No model options changes
• No profile alias scan changes
• No caching or profile system refactor
• No parallelization of per-profile cron calls

Tests

• Added a regression test that monkeypatches slow synchronous cron/profile functions and verifies the event loop can continue ticking while list_cron_jobs() is running.
• Verified the slow-sync test fails before this change with the event loop fully blocked.
• Existing cron/web server tests pass.

Risk

Low. The offloaded functions are synchronous profile/cron operations and do not access request, WebSocket, or event-loop objects. The cron path already serializes profile-local cron module access via _CRON_PROFILE_LOCK.

Related: #45072