ESD-1703: Fix MCR prefix filter list ge/le encoding

[Phil-Browne]

The SDK marshals ge/le with the wrong type on MCR prefix filter list create and modify. MCRPrefixFilterList goes straight on the wire, and its entries hold Ge int / Le int with omitempty, so values go out as JSON numbers where the API declares strings, and a prefix length of 0 produces no key at all. NAT gateway prefix lists get the string conversion right but drop the zero with an explicit if e.Ge > 0.

megalith does not default an absent ge: it forwards the field verbatim into netauto under NON_NULL. Absent and "0" are genuinely different requests downstream, so dropping a deliberate 0 is a behavior bug, not only a contract mismatch.

• Add MCRPrefixFilterList.toAPI(), mirroring the existing inbound converter, and call it from CreatePrefixFilterList and ModifyMCRPrefixFilterList.
• MCRPrefixListEntry.Ge/.Le and NATGatewayPrefixListEntry.Ge/.Le become *int so unset is distinguishable from a deliberate 0. Breaking for both consumers.
• NAT's toAPI emits "0" for a set zero instead of dropping it.
• Both directions share two helpers (prefixLenToAPI / prefixLenFromAPI) rather than repeating the same rule in four places.
• Decoding errors on a ge/le that is not a number and on a null entry, naming the index. Previously a bad value zeroed the field and a null entry panicked.
• toAPI refuses to send a null entry, so the SDK cannot write a list its own read path then rejects. megalith validates the entries list but not its elements, so a null faults it rather than earning a 400.
• Tests now assert the marshaled request body. The old create test stubbed a response and never looked at what it sent.

Migrating a consumer

Wrapping the existing int fields in PtrTo(...) is not a safe migration. Both consumers encode "unset" as 0, and on the provider side that is documented behavior, not an accident.

• terraform-provider-megaport's NAT prefix list schema declares ge/le as Optional + Computed with Default: int64default.StaticInt64(0), described to users as "Omit or set to 0 to match the prefix's own length". The SDK's if e.Ge > 0 was that sentinel's only implementation. With it gone, every entry the user left unbounded sends a real le: "0" instead of nothing, which is a different request.
• "Map unset to nil" is not reachable from that schema as written: an attribute with a static default never reports IsNull(), and returning a null on read where the plan holds 0 fails the apply with "Provider produced inconsistent result after apply". A correct migration has to drop the defaults as well, which is a second breaking change for provider users.
• megaport-cli (mcr_inputs.go) flattens its own pointer to a 0 default, and the provider's mcr_prefix_filter_list_utils.go tests if entry.Ge == 0 || entry.Le == 0.

Those updates land in their own tickets. Treat the provider one as a gate on bumping the SDK there, not a follow-up.

What I could not verify

• Integration tests were not run. They need staging credentials and create real MCRs.
• Two integration-test expectations changed from Ge: 0 to Ge: nil. The API looks like it omits ge from the response when it equals the prefix length: the pre-existing test sends Ge: 24 on a /24 and expected 0 back. Under the old int type, 0 meant "absent or zero", so the expectation was ambiguous. Two risks here, both needing a credentialed run: now that a correctly typed "24" goes out, the API may start echoing ge back and these assertions would fail; and if the API ever returns "ge": "0", nil is the wrong expectation.
• Nothing enforces ge/le anywhere in the declared contract: the spec types them as plain string with no pattern or bounds (its description names 0 to 32 and 0 to 128, but nothing checks it), and megalith holds them as opaque nullable strings. So a negative value is more likely forwarded to netauto than rejected, and ge > le has never been checked. Range validation is deliberately out of scope here.
• What ge/le of 0 actually does. The spec's description puts 0 inside the valid range and says nothing about its meaning, megalith forwards the string untouched, and netauto declares a bare int32. This is the highest-consequence unknown and the reason the provider migration is a gate: a consumer that migrates a stray 0 sends a deny nobody has characterized.
• PrefixListRequest declares no id property, but the SDK sends "id": 0 on create and the body's own id on modify (which can disagree with the path). Pre-existing and left alone per the ticket's scope; the spec sets no additionalProperties: false and megalith ignores unknown properties, so it is harmless today. Worth its own ticket.