fix(model): preserve elicitation property order

[nightcityblade]

What Problem This Solves

ElicitationSchema.properties uses a BTreeMap, so deserializing a server-declared form sorts its fields alphabetically. Clients could not recover the presentation order from the typed model.

Why This Change Was Made

The public properties field, constructor, and builder remain BTreeMap-based to avoid a breaking API change. Deserialization now uses an internal IndexMap wire representation to capture encountered property names in a new serde-skipped property_order: Option<Vec<String>> field. IndexMap is therefore not exposed in the public API.

User Impact

Clients can render deserialized elicitation fields in server-declared order by consulting property_order, while existing code using properties remains source-compatible within 3.x.

Evidence

• cargo test -p rmcp --all-features --lib test_legacy_enum_schema_roundtrip_preserves_enum_names — passed
• cargo +nightly fmt --all -- --check — passed

Fixes #1109

[DaleSeo]

@nightcityblade Thanks for addressing my comment. The no-local test fix looks good.

Sorry to bring this up late, but I noticed the ! in the commit message and realized this is a breaking change. We just cut v3, so merging this would make release-plz publish v4. It would also make indexmap a public dependency.

Could we fix the ordering within 3.x instead? I think we could keep properties: BTreeMap and store the wire order as explicit metadata, like this:

pub struct ElicitationSchema {
    // ...
    pub property_order: Option<Vec<String>>,
}

Let me know if this would work as a fix.

[nightcityblade]

Thanks for the suggestion — the metadata approach works without changing the public properties type.

I updated the PR so that:

• ElicitationSchema::properties, its constructor, and the builder remain BTreeMap-based.
• Deserialization captures the encountered keys in a new serde-skipped property_order field.
• IndexMap is used only inside the private wire representation, so it is not exposed in the public API.
• The branch is now a single non-breaking commit, removing the commit-lint failure caused by the earlier ! marker.

Validation passed with cargo test -p rmcp --all-features --lib test_legacy_enum_schema_roundtrip_preserves_enum_names and rustfmt checking. Could you take another look?