Implement execution-time validation for slice decorators with named value groups

* Problem: Slice decorators fundamentally incompatible with named value groups
  - Slice decorators strip away key information needed for map reconstruction
  - Results in silent failures where decorators don't affect consumers

* Solution: Add execution-time validation in paramGroupedCollection.Build()
  - Block slice consumption when slice decorators exist with named values
  - Provide clear error message directing users to map[string]T decorators
  - Preserve all existing functionality for valid use cases

* Implementation details:
  - Added groupHasNamedValues() helper to detect named values in groups
  - Added hasSliceDecorator() helper to detect slice-type decorators
  - Validation triggers only when both conditions exist (no false positives)
  - Removed TODO comment at param.go:665 - issue resolved

* Comprehensive edge case testing:
  - Multiple decorators (correctly forbidden)
  - Map decorators with unnamed values (fails correctly)
  - Mixed named/unnamed values with slice decorators (blocked)
  - Empty group decoration (works correctly)
  - Cross-scope decoration behavior (documented baseline)
  - Decorator chaining and value addition scenarios

* Cross-scope behavior clarification:
  - Added baseline tests for existing slice decoration behavior
  - Confirmed map and slice decorators have identical cross-scope semantics
  - Decorators only see values in their scope context
  - Child-provided values not visible to parent decorators

Key finding: This resolves the critical TODO comment by preventing the
problematic pattern rather than trying to handle the impossible case of
converting slice decorator output to map format while preserving keys.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: jquirke