utils: migrate set_target_region to Tools API

[AkshadSonawane]

Continuing the Tools API migration from #6950, which covered get_region and get_location_proj_string. Two more functions in utils.py still used the old gs.* style — this cleans those up.
set_target_region now uses Tools(env=tgt_env).g_region(...) instead of gs.run_command. get_region_bounds_latlon switches to Tools().g_region(flags="bp", format="json").json — the -g flag is dropped since it was only needed for shell-script output formatting, which format="json" makes redundant.
I left update_region alone for now. Its return value gets unpacked by _update_output in interactivemap.py using long key names (north, south, etc.), and I wasn't confident the Tools API JSON output uses the same keys without a live environment to test against. Happy to revisit that one if there's a clean way to verify it.

[echoix]

It's probably not a problem in this file, but we just have to watch out that our low-level library functions don't depend on high level functions, creating a circular dependency, which could cause import problems.

[petrasovaa]

Please test this locally.

[AkshadSonawane]

It's probably not a problem in this file, but we just have to watch out that our low-level library functions don't depend on high level functions, creating a circular dependency, which could cause import problems.

Good catch — checked and Tools comes from grass.tools which sits below grass.jupyter in the dependency chain, so no circular dependency here. Good thing to keep in mind for future migrations though.

[AkshadSonawane]

Please test this locally.

Tested locally. The screenshot shows Tools(env=tgt_env).g_region(...) — the exact pattern used in set_target_region — working correctly against a compiled GRASS 8.6.0dev build. Region values are set and verified via gs.region().
Also reverted get_region_bounds_latlon — the Tools API JSON output doesn't include the ll_* keys that function relies on, so that migration isn't safe without a geographic projection to test against. Updated the PR title to reflect that only set_target_region is being migrated.

[AkshadSonawane]

Hi @petrasovaa,

I added a basic sanity test to ensure set_target_region is callable after the Tools API migration.

While attempting to write a full integration test using session_with_data, I ran into some ambiguity around the expected function signature and environment handling (especially regarding source vs. target environment usage).

Would you recommend a preferred testing pattern for this function, or should it be covered at a higher integration level? I’d be happy to expand the test coverage based on your guidance.

Thanks!