[Bug] get_backend() returns wrong backend when folium import fails

[Photon079]

Describe the bug

The get_backend() function in python/grass/jupyter/interactivemap.py has an issue in how it handles import failures. If importing folium fails, the function immediately returns "ipyleaflet" without actually checking whether the given object is an ipyleaflet.Map.
This means the backend is sometimes guessed instead of being determined based on the actual object type, which can lead to incorrect behavior in downstream map operations.

To reproduce

1. Create a folium.Map object
2. Simulate a situation where folium cannot be imported (for example, by mocking sys.modules)
3. Call get_backend() with that object
4. The function returns "ipyleaflet" even though the object is not an ipyleaflet.Map

---

Expected behavior

Ideally, the function should:

• Check the type of the object before deciding the backend
• Try both folium and ipyleaflet (if available) instead of assuming
• Not rely on import failure as a signal for backend type
• Raise a ValueError or return a clear fallback (like "unknown") if the type cannot be determined

---

Screenshots

Not applicable — this is a logic issue.

System description

• Operating System: Windows
• GRASS version: 8.4.2
• Python: 3.12+

---

Additional context

This came up while writing tests for get_backend(). While mocking import failures, it became clear that the function skips proper type checking and falls back to assumptions.
Since this function is used internally by grass.jupyter.InteractiveMap (for example when adding raster or vector layers), incorrect backend detection could lead to subtle bugs, failed renders, or unexpected crashes when dependencies are missing or partially available.

[Photon079]

Hi @petasrovaa

I came across this issue while working on tests for grass.jupyter (GSoC test tasks).
I’ve opened PR #7240 with a fix and corresponding tests.

Would appreciate your feedback.