fix(DIARCHERS-1547): MCP trigger toggle is a no-op on first click

[Jiachen0715]

Summary

Fixes a frontend bug on the User Settings → MCP Tokens page where the
per-token Trigger switch did nothing on the first click. Users had to
click it twice (and refresh) before allow_trigger actually changed on the
backend.

Root cause

The md-switch @change handler fired before v-model had written the
new value back to token.allow_trigger. toggleMcpTrigger then read that
stale value and sent it to the backend:

// before
<md-switch v-model="t.allow_trigger" @change="toggleMcpTrigger(t)">

toggleMcpTrigger (token) {
    const newVal = token.allow_trigger   // stale — not yet updated by v-model
    UserTokenService.setMcpTrigger(token.token_id, newVal)
}

setMcpTrigger picks the HTTP method from that value
(allow ? POST : DELETE), so the first click sent the current state — a
no-op. The second click read the value left over from the previous
interaction and only then appeared to work.

Fix

Use the new value emitted by @change ($event) instead of reading
token.allow_trigger, and keep the local model in sync with it. This
matches the existing, working pattern in AdminClusters.vue
(@change="setCluster(c.name, $event)").

// after
<md-switch v-model="t.allow_trigger" @change="toggleMcpTrigger(t, $event)">

toggleMcpTrigger (token, newVal) {
    token.allow_trigger = newVal
    UserTokenService.setMcpTrigger(token.token_id, newVal)
        .catch(() => { token.allow_trigger = !newVal })   // roll back on failure
}

Impact

• User-facing correctness/security: previously a user could believe they had
  disabled trigger permission while the backend still allowed builds to be
  triggered.
• Frontend-only change. The backend API
  (POST/DELETE /api/v1/mcp/tokens/<id>/trigger) was already correct
  (verified via curl and end-to-end through the MCP client).

Testing

• Manual: toggle the Trigger switch once → refresh → state persists
  (verified against test/prod build after deploy).

[liuwei08]

LGTM