Refactor batch 1: extract core settings and configuration assembly

[DaanRijpkema]

Core settings definitions and API configuration assembly still lived in bluem.php, mixing WordPress reads and display labels with field structure and default resolution. This batch moves the schema into BluemCoreOptions and saved-value/default resolution into the shared BluemConfigurationBuilder.

Existing procedural entrypoints remain compatibility adapters. Literal gettext calls and recipient escaping stay in the WordPress wrapper so translation extraction is preserved. The builder accepts any ordered feature definitions and has no WordPress or gateway dependency, allowing future feature services to share it through composition.

No functionality changes: field definitions, defaults, feature precedence, optional module handling, saved value types, and the returned stdClass remain unchanged. The already-merged BluemOptionLookup is reused; module-status extraction belongs to existing PR #68 and is excluded here.

Validation:

• Full Unit suite: 89 tests, 213 assertions on PHP 8.4.24 (15 new cases).
• The four adapter characterization tests also pass against the original master implementation.
• Complete schema contract fixture captured before extraction, including translated labels and escaped notification recipient.
• Coverage includes missing/null defaults, false/zero/empty saved values, unknown keys, ordered feature overrides, unavailable optional modules, and fresh values on subsequent calls.
• Changed PHP files lint cleanly; Composer validation and git diff --check pass.
• All nine CI checks passed: PHP 8.4/8.5, WordPress settings/checkout/smoke, HPOS integration, browser tests, isolated E2E, and WordPress 7.1 compatibility. Real WordPress checks ran in CI because local Docker was unavailable.

Isolation: this branch starts from master and is independent of bugfix PR #85. Future request-lookup and payment-transition batches own different methods/files. A three-way merge check confirmed no conflicts with #85. The updated roadmap describes shared service boundaries and requires explicit sub-batch labeling for any future dependent PR.