feat: add optional separate GitHub token for runners polling

[skylenet]

Summary

• Add optional runners_token config field for listing self-hosted runners separately from the dispatch token
• Update status endpoint to expose rate limits for both GitHub clients (runners and dispatch)
• Update UI StatusIndicator to display rate limits for both clients separately

Details

When runners_token is configured, the system uses two separate GitHub clients:

• Runners client: Uses runners_token for polling runner status
• Dispatch client: Uses token for triggering workflows

If runners_token is not set, both operations fall back to the main token.

The /api/v1/status endpoint now returns:

{
  "github": {
    "runners": { "status": "healthy", "rate_limit_remaining": 4850, ... },
    "dispatch": { "status": "healthy", "rate_limit_remaining": 4900, ... }
  }
}

Test plan

• Build and run server with only token configured - verify both clients show same rate limits
• Build and run server with both token and runners_token - verify separate rate limits shown
• Verify UI StatusIndicator displays both clients correctly
• Verify runner polling works with runners_token
• Verify workflow dispatch works with token