fix(integrations): read every service mark from one registry - #6682

A service looked like itself on the canvas and like nothing in particular
everywhere it was connected. `OAUTH_PROVIDERS` registers 93 icons and no colour
at all, so the surfaces built on it — the connect dialog above all — drew a flat
grey mark for a block whose config already carries its brand icon and `bgColor`.

Bridges the two: `resolveIntegrationBlockTypeForOAuth` maps any OAuth id (a
service id, a provider id, an extra authorization server) to the catalog block
behind it, so a credential surface holding only an OAuth identity can still
reach the registry. The connect dialog now wears the block's tile, and
`ChipModalHeader` takes a rendered mark so a tile can carry its own chrome
instead of being tinted with the header's grey.

Folds in the copies that had grown around the gap: `IntegrationTile` resolved
its fill from the registry but took its icon from whatever the caller passed —
one tile, two sources — and now defaults to the registry, with an override kept
for the family service-account marks that genuinely are not the block's. The
letter fallback it grew alongside was reading the catalog's `bgColor` while the
tile beside it read the registry's; both are the tile now. Two `getProviderIcon`
implementations for the same job (one tinted, one not) become one `ProviderIcon`,
the connector tile duplicated verbatim across two knowledge-base surfaces becomes
one `ConnectorTile`, and the permission rows that hardcoded `text-white` — which
renders white-on-white on a pale brand tile — go through `BlockTile`.

Public pages keep their generated catalog: importing the registry there would
ship 282 block configs to a marketing page, and `integrations.json` is generated
from the same `bgColor`, so the two cannot drift.

Sweeping the surfaces above turned up colour data nothing reads and colour data
two surfaces disagreed on.

Dead: `BLOCK_COLORS.DEFAULT/LOOP/PARALLEL` in the tag dropdown (only `VARIABLE`
was ever referenced), `BlockIconInfo.color` on table columns — whose consumer
documents that it deliberately ignores the colour, so the `#2F55FF` behind it
could never render — and the `bgColor` threaded into the add-resource dropdown,
whose row renders a bare tinted icon.

Disagreeing: the Variables tile is `#2F8BFF` in the tag dropdown and `#8B5CF6`
in the preview panel, for the same "V" on the same concept. Both now read
`VARIABLE_TILE_COLOR`, and the preview panel's two hand-rolled squares become
`BlockTile` like every other tile.

Four spellings of the neutral fallback (`#6B7280`, `#6b7280`, `#666666`, and a
`cancelled` status that happened to equal it) now point at
`DEFAULT_BLOCK_TILE_COLOR`.

The terminal and logs resolvers stay. They look like duplicates of `accent.ts`
but carry behaviour it does not have — status fills for synthesized
error/validation/cancelled rows, near-black contrast correction, MCP tool-id
parsing, and a model-provider branch — so folding them in is a behavioural
change, not a deletion.

The workflow panel's copilot tab renders `MothershipChat`, and that component
brings its own input — so `panel/components/copilot` no longer holds a
component at all, only the hook library the old input used. Five of those hooks
have no caller anywhere: `useMentionData`, `useMentionKeyboard`,
`useCaretViewport`, `useMentionInsertHandlers`, `useTextareaAutoResize`.

They are not all of it. `home/components/user-input` still imports
`useFileAttachments`, `useMentionMenu`, `useMentionTokens`,
`useContextManagement`, and `useIntegrationAutoMention` from this directory,
so it survives as a shared hook library rather than dead weight — which is why
this removes the uncalled five rather than the folder.

What they alone reached goes with them: `getFolderData` / `getFolderLoading` /
`getFolderEnsureLoaded` and the `FOLDER_CONFIGS` table describing every mention
folder, `buildMentionHighlightNodes`, the `MentionFolderNav` type, and the
slash-command tables. Of the 266-line constants file only `SCROLL_TOLERANCE`
had a live reader left.

Two integrations can share one OAuth id: Google Slides is authenticated by
Drive's `google-drive` service and Jira Service Management by Jira's `jira`.
Indexing first-write-wins made those ids resolve to whichever sorted first, so
the dialog connecting Slides could wear Drive's brand.

An id claimed by more than one block type now resolves to neither, and the
caller keeps the service-specific mark it already had. A wrong brand is worse
than no tile.