[nexus] Clean up API versioning: chain conversions, fix module docs

[zeeshanlakhani]

This PR refactors a set of versioned type conversions to properly follow the API versioning guide's recommendations, including chaining through consecutive versions, ordering conventions, and aligning types to correctly match the ranges and where they should be defined.

Changes:

• Removes v2026011501.rs: Moves AddressSelector and FloatingIpCreate to v2026010500.rs, where they were actually introduced (POOL_SELECTION_ENUMS, not AUDIT_LOG_CREDENTIAL_ID).

• Fixes conversion chains: Types now chain through consecutive versions:

  • v2026010500 → v2026011600 → params (not v2026010500 → params directly)
  • Adds From implementations in v2026011600.rs for conversions from v2026010500 to next, latest versions

• Updates module docs: All version modules now use the correct format per the guide:

  • Types from API version X (VERSION_NAME) that changed in version Y (NEXT_VERSION_NAME)
  • Per-section validity docs for modules where different types changed in different later versions

• Endpoint chains: lib.rs endpoints correctly delegate through consecutive versions where types changed

[sunshowers]

Thanks. The general direction looks good here. My concern is just merge conflicts with others, and the fact that when we convert the external API to RFD 619 (after the next release) we'll re-evaluate all of this anyway.

What do you think?

[zeeshanlakhani]

Thanks. The general direction looks good here. My concern is just merge conflicts with others, and the fact that when we convert the external API to RFD 619 (after the next release) we'll re-evaluate all of this anyway.

What do you think?

@sunshowers Yeah, I was trying to be consistent with the docs/guidelines :). I've been used to many upon many of merge conflicts with API changes already, but if the cut over to capture RFD 619 is happening soon, then maybe it's not necessary?

I'm ok to close it too, up to you @sunshowers.