Preserve integer precision in AdditionalProperties via UseNumber

[charlie-zhang109]

Fixes #4091.

Summary

The generated UnmarshalJSON for every model with an additionalProperties block populates AdditionalProperties map[string]interface{} via datadog.Unmarshal, which is a thin wrapper around encoding/json.Unmarshal. The standard Go decoder unmarshals JSON numbers into interface{} targets as float64, so integers above 2^53 silently lose precision. Typed schema fields decode into concrete *int64 targets and are not affected.

This PR switches the additionalProperties decode to a UseNumber-enabled decoder via a new datadog.UnmarshalUseNumber helper.

Changes

• .generator/src/generator/templates/encoding_json.j2 — add UnmarshalUseNumber to the stdlib JSON backend.
• .generator/src/generator/templates/goccy_gojson.j2 — add UnmarshalUseNumber to the goccy_gojson backend.
• .generator/src/generator/templates/model_simple.j2 — one-line change: the additionalProperties decode now calls datadog.UnmarshalUseNumber instead of datadog.Unmarshal.

Templates-only — happy to regenerate the rendered output into the same PR if reviewers prefer that.

Behavioral contract change

After regeneration, values in AdditionalProperties will be json.Number (string-backed) rather than float64.

• Callers using val.(float64) will break.
• Callers using val.(json.Number).Int64() or .Float64() get correct precision.

Suggest changelog/Changed + backward-incompatible labels.

Test plan

• Regenerate output via the apigentools flow and confirm the diff in api/datadog/encoding_json.go, api/datadog/goccy_gojson.go, and the ~100+ affected model_*.go files matches expectation.
• CI on the regenerated PR (unit tests + cassette-based integration tests).
• Targeted unit test: round-trip an integer > 2^53 through a model with additionalProperties and assert exact recovery via .(json.Number).Int64(). Happy to write this — flag if you'd like it in this PR or as a follow-up.