Add support for saving color stops in symbologyState

[nakul-py]

Description

Now when user open symbology everytime classified Color Stops is visible.

Screencast.From.2025-10-07.17-01-30.mp4

• Closes Single band pseudocolor classification stops disappear each time the symbology menu is re-opened #947

Checklist

• PR has a descriptive title and content.
• PR description contains references to any issues the PR resolves, e.g. Resolves #XXX.
• PR has one of the labels: documentation, bug, enhancement, feature, maintenance
• Checks are passing.
  Failing lint checks can be resolved with:
  • pre-commit run --all-files
  • jlpm run lint

---

📚 Documentation preview: https://jupytergis--949.org.readthedocs.build/en/949/
💡 JupyterLite preview: https://jupytergis--949.org.readthedocs.build/en/949/lite

[github-actions]

👈 Launch a Binder on branch nakul-py/jupytergis/fix947

[github-actions]

Integration tests report: appsharing.space

[mfisher87]

This PR looks good, but it faces some challenges with how this change interacts with the min/max fields in the object properties dialog.

If one classifies the data from 0-1000, then changes the max to 500 in the object properties dialog, the map re-renders, but does not update the classification stops, leaving the classification stops in an incorrect state.

IMO, we should:

• Remove the color state from the JSON and calculate this information dynamically from the symbologyState every time it changes. Holding two pieces of state like this risks them going out of sync! That could go in this PR, but it's a fairly significant overhaul that should apply to every layer type and may take some time to complete.
• Remove the min and max fields from the object properties dialog, and fix the min/max fields in the symbology menu to correctly display the underlying value (source.urls[0].min|.max. In Support divergent color ramps #912, source.urls[n].min|.max are being completely removed from the schema, so there would be a conflict between these two PRs. Given the size of Support divergent color ramps #912, it's daunting to reconsider the min and max fields and their interaction with the colormap. I think the ultimate correct decision would be to store the user-selected min and max in the JSON on a per-band basis, but it's probably prudent to go about this in baby steps. Maybe the first step is to remove the fields from object properties and use the min/max fields in the symbology menu to display and update the same underlying data (source.urls[0].min|.max), then later on deal with saving band-specific mins and maxes. This way the rendered data will only update when changing the symbology menu.

[mfisher87]

#963 This looks like the easy solution to our problem! Then we can save/load stops from the color property just like vector layers.