Reject aggregation parameters that silently fall back or change semantics #674

What happened

Some malformed or omitted aggregation parameters are silently replaced with defaults or interpreted as a different operation. Examples include missing or non-boolean count-events configuration defaulting to true, invalid HLL precision falling back to the default precision, and unrecognized Min/Max subtypes being interpreted as Min.

What I expected

Missing parameters should be defaulted only when omission is explicitly supported. Present-but-invalid parameters must fail configuration or plan creation with a clear error. A typo must never change the aggregation semantics.

Steps to reproduce

1. Create an aggregation configuration with a malformed parameter type, out-of-range HLL precision, or misspelled Min/Max subtype.
2. Build the corresponding accumulator or streaming plan.
3. Observe that construction succeeds with a default or different semantic operation.

Additional context

Use explicit parsing that distinguishes missing from invalid values. Validate ranges and accepted enum values at the planner/configuration boundary, and add regression tests for each invalid case.

Concrete examples

These configurations should be rejected:

count_events: yes
precision: 20
min/max subtype: Mxa

Current behavior can interpret them as:

count_events: true
precision: 14
operation: Min

That means a typo can change the aggregate while the plan still succeeds. Missing values may use an intentional default, but present values with the wrong type, invalid range, or unknown enum value must return an error.