Standardize enable option handling across all plugins

[watson]

What and why?

The six user-facing plugins (apps, error-tracking, live-debugger, metrics, output, rum) each had a divergent implementation for resolving their enable config boolean:

• Two code patterns: apps and live-debugger used explicit ?? nullish coalescing, while the other four used a spread-override trick (enable: !!config[KEY], ...config[KEY]) that relies on property ordering.
• Inconsistent validation: Only live-debugger rejected non-boolean values; the rest silently coerced.
• Incomplete docs: output and metrics documented default: true (misleading — it's false when the config block is absent), error-tracking had no enable section at all, and rum had no README (lost in the sourcemaps extraction refactor of 804f917).

This PR standardizes all three axes so future plugins have a single pattern to follow.

How?

Shared helper (@dd/core/helpers/options):

• resolveEnable(options, configKey, log) — single source of truth for resolving enable. Emits a deprecation warning (once per key) when a non-boolean value is passed, but still coerces it with !! to avoid breaking existing users. Strict rejection is deferred to the next major.
• validateEnableStrict(pluginConfig, errors) — pushes a hard validation error for non-booleans. Used only by live-debugger, preserving its existing contract.

Plugin refactors:

• All six validators now call resolveEnable() instead of ad-hoc logic. apps and output gained a log parameter (call sites updated). For the spread-override plugins, enable is now set after the spread so it can never be silently overwritten.

Documentation:

• Every plugin's README now has a consistent ### <key>.enable section with the correct default wording: "true when a <key> config block is present, false otherwise."
• error-tracking gained its missing enable section and TOC entry.
• A full rum README was authored covering enable, sdk.*, privacy.*, and sourceCodeContext.*.

Tests:

• 15 new tests for the shared helper (coercion, warn-once, strict validation).
• Each plugin's validate tests extended with non-boolean enable cases asserting the deprecation warning.

[watson]

• Standardize enable option handling across all plugins #324 👈 (View in Graphite)
• Add live-debugger plugin #296 : 1 other dependent PR (#325 )
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[yoannmoinet]

Looks mostly good.

I wonder if we could handle one level higher than just resolveEnable and have something like a global validateOptions, that would, for now, validate enable.

It would be called from each plugin, but would be implemented, tested and documented just once.
Since this is a standard, this can be documented just at the root, once, and not for each individual plugin.

Or alternatively, handle this at the factory level directly, where we also have an validateOptions too.

build-plugins/packages/factory/src/index.ts

Lines 176 to 190 in 00679a8

	for (const [name, getPlugins] of pluginsToAdd) {
	context.plugins.push(
	...wrapGetPlugins(
	context,
	getPlugins,
	name,
	)({
	bundler,
	context,
	options,
	data,
	stores,
	}),
	);
	}

This way, plugins themselves don't even have to handle it.
The standard is applied by design.

I think I prefer the factory approach after all.

WDYT?

[yoannmoinet]

This already exists.

build-plugins/packages/tests/src/_jest/helpers/mocks.ts

Lines 118 to 136 in 00679a8

	export const mockLogFn = jest.fn((text: any, level: LogLevel) => {});
	export const getMockLogger = (overrides: Partial<Logger> = {}): Logger => ({
	getLogger: jest.fn(),
	time: jest.fn(() => getMockTimeLogger()),
	error: (text: any) => {
	mockLogFn(text, 'error');
	},
	warn: (text: any) => {
	mockLogFn(text, 'warn');
	},
	info: (text: any) => {
	mockLogFn(text, 'info');
	},
	debug: (text: any) => {
	mockLogFn(text, 'debug');
	},
	...overrides,
	});
	export const mockLogger: Logger = getMockLogger();

Same thing in the other test files.

[yoannmoinet]

This should live in its own PR.