grass.jupyter: use the Tools API in reproject_latlon

[Valyrian-Code]

Description

reproject_latlon ran m.proj via gs.start_command with manual PIPE
handling, communicate(), and encode/decode. This rewrites it to use
grass.tools.Tools with an io.StringIO input, matching get_region and
get_location_proj_string in the same module.

Motivation and context

grass.jupyter.utils already uses the Tools API in get_region and
get_location_proj_string. This brings reproject_latlon in line with that
and removes the manual subprocess boilerplate, in the spirit of the
"rewrite functions using the new Tools API" direction for grass.jupyter.

The output is unchanged for valid input; Tools additionally raises on a
non-zero m.proj exit instead of failing later while parsing empty output.

How has this been tested?

Verified locally that the rewritten function returns the same result as the
previous implementation, e.g. reprojecting (lat 35.7, lon -78.6) into
EPSG:3358 yields (645799.19, 216389.17, 0.0). ruff format and ruff check
are clean.

Types of changes

• Refactoring (no functional change for valid input)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Refactors reproject_latlon() to run m.proj via the Tools().m_proj() wrapper using an in-memory stream instead of manually managing a subprocess.

Changes:

• Adds StringIO import to support passing coordinates via an in-memory text stream.
• Replaces gs.start_command(...).communicate() subprocess handling with a Tools().m_proj(...).text call.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Valyrian-Code]

I took a look at this and don't think it makes sense to change right now.

• The main cost here is the m.proj subprocess itself. Both the current and proposed implementations still spawn a new m.proj process for every call, so reusing a Tools instance would only optimize a relatively cheap object construction.

• Also, reproject_latlon() is currently used once per interactive query rather than in a batch-processing loop, so there isn't a demonstrated performance issue in practice.

• For consistency, other helpers in the same file (get_region() and get_location_proj_string()) also construct Tools() on demand. Changing only this helper would make the pattern inconsistent.

• A module-level singleton would also be problematic because Tools captures its environment when constructed. If initialized before the GRASS session environment is fully set up, it could end up holding the wrong environment.

If batch reprojection ever becomes a real use case, the more effective optimization would be to send multiple points through a single m.proj invocation, eliminating the repeated subprocess launches entirely.

That would be a separate change.