Support pre-filled create mode and return the created registry in ContainerRegistryEditorModal

## Summary

\`ContainerRegistryEditorModal\` can only be opened empty (create) or from a Relay fragment (modify). A caller that already knows the registry it needs — the upcoming **Add image** modal, which parses \`nvcr.io/nvidia/...\` out of a pasted NGC URL — cannot pre-fill \`registry_name\` / \`url\` / \`project\`, and \`onOk('create')\` hands back nothing the caller can match against.

## Scope

- New optional \`initialValues\` prop for **create** mode (\`registry_name\`, \`url\`, \`project\`, optionally \`type\`), merged into the create branch of the form's initial values. Kept orthogonal to \`containerRegistryFrgmt\` so it never flips the modal into modify mode (title, disabled \`registry_name\`, password "no change", modify mutation).
- Widen the create mutation's selection set to include \`registry_name\` and \`project\` (and \`row_id\`/\`id\`), and extend \`onOk\` to pass the created registry identity alongside the existing \`'create' | 'modify'\` type. Existing call site (\`ContainerRegistryList.tsx\`) keeps working unchanged.
- Unit test covering: pre-filled create renders the values and stays in create mode; \`onOk\` receives the created registry.

## Context

Research fact sheet (FR-3935): https://github.com/lablup/backend.ai-webui/blob/research/add-image-webui-plumbing/docs/research/add-image-webui-plumbing.md §3.2–3.3. Part of the wayfinder effort FR-3933; bottom of a two-PR stack — the Add image modal builds on it.

JIRA Issue: FR-3939

Start with ContainerRegistryEditorModal and inspect its existing create and modify branches, then review ContainerRegistryList.tsx to confirm the current caller remains compatible. Read the §3.2–3.3 section of docs/research/add-image-webui-plumbing.md for context. Done means the pre-filled create case stays in create mode, and the unit test verifies that creation returns the registry identity.

Written by the indexing model from the issue text.