fix: Separate settings groups to prevent cross-tab overwrites (v0.4.5)

Split Metrics sub-tab settings into separate WordPress option groups:
- wp_prometheus_endpoint_settings for auth token
- wp_prometheus_selection_settings for enabled metrics
- wp_prometheus_advanced_settings for isolated mode

This fixes the bug where saving from one sub-tab would clear settings
from other sub-tabs due to all settings sharing a single option group.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

CLAUDE.md

@@ -291,6 +291,50 @@ add_action( 'wp_prometheus_collect_metrics', function( $collector ) {
 
 ## Session History
 
+### 2026-02-02 - Settings Persistence Fix (v0.4.5)
+
+- Fixed critical bug where settings would get cleared when saving from different Metrics sub-tabs
+- Root cause: All settings were registered under single `wp_prometheus_metrics_settings` group
+  - When saving from "Endpoint" sub-tab, only auth token was in POST data
+  - WordPress Settings API would process all registered settings in the group
+  - Missing fields (enabled_metrics, isolated_mode) would receive null/undefined
+  - Sanitize callbacks returned empty values, overwriting existing settings
+- Solution: Split into separate settings groups per sub-tab:
+  - `wp_prometheus_endpoint_settings` for auth token
+  - `wp_prometheus_selection_settings` for enabled metrics
+  - `wp_prometheus_advanced_settings` for isolated mode
+- **Key Learning**: WordPress Settings API and multiple forms
+  - When multiple forms share the same settings group, saving one form can clear settings from another
+  - Each form with `settings_fields()` should use a unique option group
+  - `register_setting()` group name must match `settings_fields()` group name
+
+### 2026-02-02 - Safe Mode & Custom Hooks Fix (v0.4.4)
+
+- Redesigned metrics collection to support both plugin compatibility AND custom metrics:
+  - **Safe Mode (default)**: Removes content filters early but lets WordPress load normally
+  - **Isolated Mode**: Legacy early mode that skips custom hooks entirely
+- Implementation:
+  - `WP_PROMETHEUS_METRICS_REQUEST` constant set for any /metrics request
+  - Content filters removed via `plugins_loaded` hook at priority 0
+  - Collector fires `wp_prometheus_collect_metrics` with protection (output buffering, try-catch)
+  - `wp_prometheus_isolated_mode` option replaces `wp_prometheus_disable_early_mode`
+  - `WP_PROMETHEUS_ISOLATED_MODE` environment variable for containerized deployments
+- Collector now wraps custom hooks in `fire_custom_metrics_hook()` method:
+  - Removes content filters again before hook (in case re-added)
+  - Uses output buffering to discard accidental output
+  - Catches exceptions to prevent breaking metrics output
+  - Logs errors when WP_DEBUG is enabled
+- Updated admin UI with mode comparison table
+- **Key Learning**: Hybrid approach for plugin compatibility
+  - The memory issue comes from content filter recursion, not just plugin loading
+  - Removing filters early (before any plugin can trigger them) prevents recursion
+  - Plugins still load and can register their `wp_prometheus_collect_metrics` hooks
+  - Hooks fire after filters are removed, in a protected context
+- **Key Learning**: Defense in depth for custom hooks
+  - Remove filters again right before hook fires (plugins may re-add them)
+  - Output buffering catches any echo/print from misbehaving plugins
+  - Try-catch prevents one broken plugin from breaking metrics entirely
+
 ### 2026-02-02 - Sub-tabs & Early Mode Fix (v0.4.3)
 
 - Split Metrics tab into sub-tabs for better organization: