[UI-REWRITE]: Move the catalog OAuth registration form from a dialog to a page

[a-effort]

Registering an OAuth server from the catalog opens CatalogOAuthDialog.tsx in a modal. The dialog is max-w-lg (ui/dialog.tsx:39) and holds nine controls: name, issuer, scopes, the redirect URI copy block, client ID, client secret, authorization URL, token URL, visibility and team. It scrolls inside max-h-[90vh] at CatalogOAuthDialog.tsx:212. That is more configuration than a modal of this width shows at once, and the redirect URI usually has to be pasted into the provider's console in another window before the client ID and secret below it can be filled in, which a modal makes awkward.

Move it to a page using the connect MCP server form's layout. MCPServerForm.tsx:186 onwards is the target: a centred max-w-3xl card, an icon and title row, an intro paragraph, and fields built with the Field wrapper from ui/field (MCPServerForm.tsx:269, :293) rather than hand assembled Label and Input pairs.

Render it the way the connect form is rendered, in place of the catalog grid on /app/server-catalog, rather than as a new route. The submit flow at ServerCatalog.tsx:684-756 then keeps the state it already reads, and returning to the grid keeps the filters in the URL and the focus handling at ServerCatalog.tsx:501-506. A separate route would also work, but it needs the register and authorise flow lifted into a hook and the catalog query preserved across the navigation.

Note: the "Configure and authorize" button label can just change to "Save".

What to keep:

• authorization_code only. Catalog OAuth does not gain the general form's grant type selector, password grant or token management controls. See the note at CatalogOAuthDialog.tsx:44-50.
• serversApi.openOAuthAuthorizationPopup() still has to run before the first await in the submit handler or the browser blocks the popup (ServerCatalog.tsx:690-692).
• The redirect URI block with its loading, error and retry states, and the submit button staying disabled until the callback URL resolves.
• Field validation with per-field messages, visibility and team selection, and the InlineNotification surface for registration and authorization failures.
• Cancel returning to the catalog with that server's row actions focused.

CatalogOAuthDialog.test.tsx drives the component through the dialog, so it changes alongside.

CatalogApiKeyDialog.tsx stays a dialog as it only has 2 fields.

Scope is the web UI, no API change, and no work on the Admin UI.

Reference for current UI:

[a-effort]

@vishu-bh , assigned this to you but feel free to pass to other folks on the team if you don't have capacity. @jonpspri (re planning)