Allow embedding the credentials screen in a shared AI settings page

[Jameswlepage]

WP AI Client currently registers its own Settings → General submenu (options-general.php?page=wp-ai-client) to render the credentials form. That’s perfect when the Composer package is installed on its own, but it breaks down as soon as multiple AI plugins ship together (e.g., the WordPress AI Experiments plugin). We'll probably want “AI” to live under a single admin entry point with subtabs such as Credentials and Experiments. Without changes in this repo, every plugin adds its own submenu and users bounce between duplicate pages to finish setup.

Problem

• API_Credentials_Manager::add_admin_screen() hard-codes the parent slug, page slug, menu labels, and description copy, so downstream plugins cannot relocate or embed the credentials UI.
• The API_Credentials_Settings_Screen instance is private to the package, which means there is no supported way to bootstrap its sections or render its form inside custom markup.
• When more than one AI-focused plugin is active, the Settings menu fills up with near-identical entries, which is confusing and doesn’t scale with the broader “AI Building Blocks” initiative.

Proposal

1. Configurable screen registration
   Add a small configuration surface (e.g., a wp_ai_client_credentials_screen_config filter) that controls parent_slug, screen_slug, menu/page titles, description, and whether WP AI Client should call add_options_page() at all. Defaults should mirror the current behavior so standalone installs keep today’s UX.
2. Expose the credentials screen object
   Persist the API_Credentials_Settings_Screen instance on the manager and expose it via a public accessor such as AI_Client::get_credentials_settings_screen(). Guard initialize_screen() so consumers can call it manually (for example, when rendering their own tab) without double-registering sections.
3. Document the extension point
   Note in the README that other plugins can opt into the shared “AI” page by overriding the config, calling initialize_screen(), and rendering the form via settings_fields( 'wp-ai-client-settings' ) + do_settings_sections( <their slug> ). The immediate consumer will be the AI Experiments plugin, which will register options-general.php?page=ai and render the credentials UI as its first tab.

Benefits

• Standalone usage of WP AI Client remains untouched (same submenu, same slug).
• When multiple AI plugins are present, they can present a unified “AI” settings surface without forking this package or duplicating the credentials form.
• Future AI features gain a clear pattern for plugging additional tabs into the shared page, keeping the admin UX coherent.

Next steps

1. Implement the configuration/filter and the public accessor inside WP AI Client (plus tests/docs).
2. Update the AI Experiments plugin to consume the new hooks and ship the combined “AI” submenu.
3. Coordinate any additional AI plugins around the same convention so the Settings menu doesn’t fragment again.