…ndpoint)

Extracted from #3784. Initializes the settings registry on every request
instead of only on `admin_init`, so registered settings are available in
non-admin contexts such as a /graphql request.

- Settings::init_registry() now runs on `init` (priority 11, after
  register_settings) in addition to the existing admin path.
- SettingsRegistry::init_registry() fires `graphql_init_settings` and
  ensures each section's option exists + is registered. It's idempotent
  (guarded per-instance) so reaching it via both `init` and `admin_init`
  in one request can't double-fire. admin_init() now delegates to it for
  the registration work and keeps only the admin-UI scaffolding.
- Experimental: the Admin class is now initialized in all contexts (it only
  does registration work), so the GraphQL endpoint can resolve experiment
  settings without depending on an admin request.

Also folds in a lint-only eslint-disable comment in the legacy wpgraphiql
GraphiQLToolbar (import/no-unresolved for @graphiql/react) so it isn't
stranded when the IDE branch is reduced to plugins/wp-graphql-ide/**.

Regression caught by tests/e2e/specs/settings-registry-options-page.spec.js:
init_registry() created each section's option via add_option( $id, [] ).
An array value serializes, and WordPress renders serialized options as a
disabled "SERIALIZED DATA" input on /wp-admin/options.php — so the e2e test
that edits graphql_experiments_settings there could no longer fill the field.

Revert to add_option( $id ) (WP's empty-string default), matching the
long-standing behavior. sanitize_options() already tolerates a string value,
so nothing downstream needs the [] seed.

The previous approach (seeding each option in init_registry, which runs on
every `init`) was the root of two test failures:

- add_option($id, []) stored a serialized array -> WordPress renders it as a
  disabled "SERIALIZED DATA" input on /wp-admin/options.php, breaking
  settings-registry-options-page.spec.js.
- add_option($id) stored an empty string -> on a /graphql or test request the
  option now exists as a scalar, so callers that array-write onto it
  (GraphQLHeadersCept: `$opt['query_analyzer_enabled'] = 'off'`) hit a PHP 8
  "Cannot access offset of type string on string" TypeError. On main this
  works because the option doesn't exist yet (false auto-vivifies to array).

Fix: init_registry() no longer creates the option row — it only fires
graphql_init_settings and register_setting() so settings resolve at the
endpoint. Option creation moves back to admin_init() (lazy, empty-string
default), matching main's long-standing behavior. Reads are unaffected:
get_graphql_setting() already defaults a missing option to [].