config validate: detect bare/null unsupported sections (true key-presence)

[shreemaan-abhishek]

Part of #22. Follow-up to review feedback on #31.

Problem

The current cfg.<Section> != nil check in pkg/cmd/config/validate/validate.go and pkg/cmd/config/configutil/configutil.go only rejects explicitly-empty unsupported sections (e.g. upstreams: []). It does not reject:

• upstreams: (bare key, no value) — unmarshals to nil
• upstreams: null — unmarshals to nil

Same for consumer_groups and service_templates. A user who declares any of these forms gets silent acceptance.

Fix

Two-pass parse: first into map[string]yaml.Node (or map[string]json.RawMessage for JSON), check whether the key is present at all, then decode into the typed api.ConfigFile. If a key for an unsupported section is present, reject regardless of value.

Tests

Extend TestConfigValidate_EmptyUnsupportedSections (or add a sibling table) with cases:

• upstreams: (no value)
• upstreams: null
• consumer_groups: / consumer_groups: null
• service_templates: / service_templates: null

All should produce the same "X are not supported" error as the existing [] cases.

[shreemaan-abhishek]

Severity assessment: close to cosmetic, not a GA blocker

After review, this is a completeness/consistency gap in validation messaging, not a correctness bug.

What slips through today: upstreams: (bare key), upstreams: null, and the same for consumer_groups / service_templates.

What that means in practice: the user wrote a key that declares zero resources. There is nothing for the validator to act on. No unsupported resource gets created. No silent acceptance of bad data. The only thing missing is a "you mentioned an unsupported section" error in a case where nothing would have gone wrong functionally anyway.

The motivating cases: upstreams: [] and upstreams: [{...}] are both already rejected.

Realistic paths to hit this:

• Typing upstreams: as a placeholder to fill in later (no consequence)
• A YAML editor / formatter normalizing an empty value to null (no consequence)

Recommendation: keep this open as a low-priority cleanup, but treat it as out of GA exit criteria. Land it post-GA if there are spare cycles. Don't block the release on it.