origin: record scalar-valued mapping keys as a sequence

[reuvenharrison]

What

addOrigin already records per-item locations for sequence-valued fields under a mapping's __origin__. This extends it to also record the keys of a scalar-valued mapping (a map of atomic values) into the same sequence slot, addressable by name.

Why

A scalar-valued mapping, e.g.

labels:
  env: production
  region: us-east

decodes into a Go map[string]V with scalar V, which carries no Origin field of its own. The per-key __origin__ injected on the nested mapping node is therefore lost on decode, so a consumer has no way to locate an individual entry. The only place a key's location can survive decode is on the parent object's origin, which does have somewhere to store it.

Recording the keys as a sequence under the parent (reusing the existing sequences encoding, items addressable by name) makes each entry's location reachable by consumers that already read Origin.Sequences.

Object-valued mappings are unaffected: each of their values is itself a mapping that already carries its own __origin__, so isScalarValuedMapping gates them out to avoid redundant data.

Tests

TestOrigin_Map and TestOrigin_MapOfScalars are updated to reflect the new sequence section (the parent now records the scalar-map keys); TestOrigin_MapOfScalars gains a doc comment explaining the behavior. Full suite passes.

[reuvenharrison]

Superseded: no yaml3 change is needed. The per-map-entry key locations are already present in the OriginTree (verified against released v0.0.14); they were only being discarded downstream when a scalar-valued mapping decodes into a Go map with no Origin field. The fix belongs in kin-openapi's applyOrigins (the layer that knows a field is a map[string]scalar), which also avoids the over-firing this PR caused on schema objects. Closing in favor of the kin-side change.