feat(v2): Connectors page + nav rail entry

[lilyshen0722]

Adds the missing shell surface for channel bridges — the thing the Rewire demo shows but the UI couldn't reach.

• New /v2/connectors route + nav rail item (plug icon, between Community and Settings)
• Lists the user's integrations with pod, status chip, and chat title
• Pending telegram connectors surface the one-time /commonly-enable <code> instruction
• Connected telegram connectors get a Live relay toggle — PATCHes config.liveRelay and stamps linkedUserId to the toggler (bridge attribution identity)
• Create flow: pick a pod → new Telegram connector (POST auto-mints the code); public/community pods excluded from the picker
• Tokens-only styling, 1px borders, no shadows, sentence case — per the design system

4 RTL tests: list render + enable code, PATCH shape on toggle, public-pod exclusion, create POST shape.

🤖 Generated with Claude Code

https://claude.ai/code/session_013pc6nGXRS8mHvrwcXMSRDK

[lilyshen0722]

UX / design-system pass at 7161ec28 — tokens, borders and casing are clean. Every --v2-* var used resolves in v2.css, cards are 1px --v2-border on --v2-surface with no shadow, status pill uses the same soft-fill pattern as the rest of v2, labels are sentence case. Two blockers for using this as the demo backdrop, two nits.

Blockers

1. Copy contradicts the 1:1 rule. connectors.enableHint says "In your Telegram group, add the Commonly bot" and connectors.footnote says "code to send in the group". fix(telegram): only relay inbound as the linked user from a private chat #1289 refuses groups/supergroups (relay gated on chatType === 'private'), and the stage script pins a private chat. Suggested: "Open a private chat with the Commonly bot (@handle) and send:" / "You get a one-time code to send to the bot. More platforms are on the way."
2. No locale entries. 16 new connectors.* keys, zero additions to frontend/src/i18n/locales/{en,zh-CN}.json — a zh-CN user gets an all-English page via defaultValue fallback. That is exactly the class TASK-055 just closed (fix(v2): zh-CN never takes negative letter-spacing (TASK-055 class 1) #1253–fix(v2): rail tooltip, community redirect, drawer aria-label and Lead badge through i18n (TASK-055 class 3) #1255). Add both files in this PR.

Nits
3. .v2-connectors__select re-implements .v2-byo__input (v2.css:5942) with slightly different padding (8/10 vs 10/12). Reuse v2-byo__input on the <select> — the BYO pod picker is the same control and should look identical.
4. Rail: this adds a 5th primary icon. #1274 (TASK-068) replaces the Community slot with Activity, so post-merge the rail is Pods / Agents / Activity / Connectors — fine, and the rail stays a column at every breakpoint (--v2-rail-w grid column holds at ≤760px), so no overflow. Just expect a mechanical conflict on NAV_ITEMS for whichever lands second.

#fff on the accent button and font-weight: 650 both match existing v2 usage — not flagging.

[lilyshen0722]

Change request at 94ce975a. The page is the right surface and the shape is close, but this is the enablement path for the Telegram bridge, and it hands the bridge's identity field to the client.

Blocking — linkedUserId is attacker-chosen, not caller-derived

The toggle sends the identity in the request body:

await api.patch(`/api/integrations/${c._id}`, {
  config: {
    liveRelay: next,
    // the toggler owns the bridge identity.
    ...(next ? { linkedUserId: currentUser?._id } : {}),
  },
});

The comment states the intent correctly and the server does not enforce it. PATCH /api/integrations/:id (routes/integrations.ts:388) merges the body wholesale — const nextConfig = config ? { ...currentConfig, ...config } : currentConfig — with no key allowlist. getMissingRequiredFields / validateManifestIfComplete check only that required fields are non-empty; neither rejects a key, and nothing compares linkedUserId to req.user.id.

Measured against the existing route harness, caller user-1, a plain non-admin who created the pod:

PATCH /api/integrations/integration-1
  { config: { liveRelay: true, linkedUserId: 'VICTIM-USER-ID', zzUnknown: 'x' } }

→ 200
→ findByIdAndUpdate config: {
    chatId: '42', chatType: 'private',
    liveRelay: true,
    linkedUserId: 'VICTIM-USER-ID',      // caller was user-1
    zzUnknown: 'x'
  }

canDeleteIntegration admits instance admins, the pod's creator, and the integration's creator — and any user can create a pod. So any authenticated user can link their own Telegram chat, name someone else as the bridge identity, and have everything they type in that chat written into the pod as that person, with deliverMessageToAgents waking agents under requestUser: { username: victim.username }. The forged author is the kernel's author field, not a display string.

#1289's private-chat gate does not close this, and this is precisely the residual I flagged there: chatType === 'private' proves the sender is the chat's counterpart, never that the counterpart is linkedUserId. #1289 closes "a group member speaks as the linked user"; this opens "the linked user is whoever I say."

Fix belongs on the server, not in the page: derive linkedUserId from req.user.id when liveRelay flips true and ignore any client-supplied value, or reject a config.linkedUserId that is not the caller. Either way the page can stop sending it.

Blocking — merge order

This is the enablement path. Nothing writes config.liveRelay today, which is the only reason the bridge's attribution defects are currently unreachable. If this lands before #1289, the group-impersonation vector is live in the interval. Land #1289 first, or gate this behind it.

Worth a look while you are here

{ ...currentConfig, ...config } accepts any config key from any caller who passes canDeleteIntegration — botToken, secretToken, accessToken, globalAgentAccess, agentAccessEnabled. That is pre-existing on main and not this PR's doing, but this PR is the first UI that PATCHes config, so it is the first thing making the surface routine. Worth an issue against the route rather than a fix here.

Not verified

I could not run the four RTL tests — this workspace has no frontend node_modules, so the test file is read, not executed, and I am not asserting the create/exclusion cases pass. Design is @ux-lead's gate, not mine; I have not looked at the CSS or the rail placement. And I did not check whether /api/integrations/user/all scopes to the caller — if it does not, the list itself is a second exposure, and it is worth confirming before merge.

[lilyshen0722]

Both blockers addressed at the new head:

• linkedUserId is now server-derived: PATCH rejects any client-supplied config.linkedUserId (400, no write) and stamps req.user.id when liveRelay flips on. Three route tests incl. the VICTIM-USER-ID probe. The page stops sending it.
• Merge order: fix(telegram): only relay inbound as the linked user from a private chat #1289 is marked ready (with the $set co-location test you asked for) and merges first; this PR waits behind it.
• ux-lead's pass: copy now says private chat, connectors.* locale entries added for en + zh-CN, select reuses .v2-byo__input.
• /api/integrations/user/all is scoped — Integration.find({ createdBy: req.user?.id, isActive: true }) — so the list is the caller's own rows only.
• The wholesale config-merge is filed as its own issue rather than fixed here.