grass.temporal: set backend when init() skips database creation

[gkneighb]

Summary

init(skip_db_init=True) returned before setting the tgis_backend global, so get_tgis_backend() was None after it — even though init()'s own docstring documents that skip_db_init still provides "the global TGIS state (backend, mapset, interfaces)".

The regression test grass_temporal_core_init_skip_db_test.py::test_init_succeeds_without_db_creation asserts get_tgis_backend() == "sqlite", but that only held when its sibling test_init_creates_tgis_db_if_not_skipped ran first in the same process and set the global via a full init(). Run standalone, or split across pytest-xdist workers, it failed with assert None == 'sqlite'.

Fix

Set the backend before the early return, reading the driver name non-destructively through the C-library interface (not t.connect, whose -c flag would write the connection VAR) and defaulting to sqlite when no temporal connection is defined yet. This preserves the no-side-effect guarantee of skip_db_init (the same test still asserts not var_file.exists() and not tgis_db.exists()) while honoring the documented contract, so the test passes in isolation and under parallel execution.

How this was found

The failure surfaced on the macOS CI of an unrelated temporal PR (#7670): adding test files shifted pytest-xdist's worker distribution so the two sibling tests landed in different workers, exposing this latent ordering dependency. It reproduces on main with pytest .../grass_temporal_core_init_skip_db_test.py -n 2.

Test plan

Previously failed standalone and under xdist; now passes:

pytest python/grass/temporal/tests/grass_temporal_core_init_skip_db_test.py -n 2

Full temporal regression under parallel execution (139 passed):

pytest python/grass/temporal/tests/ temporal/*/tests/ -n auto

AI assistance

Implemented with the assistance of an AI coding assistant (Claude), reviewed and verified by the author.

[echoix]

@ninsbl I think you had a PR prepared on your fork for addressing that issue

[ninsbl]

Good catch.
Still, I would rather solve this as part of #7672 (where I solved it slightly different).

While the solution here is OK and would use a more meaningful default if a TGIS DB connection is defined in the current mapset, I think it is unnecessary to get the defaults from the current mapset, because if the SQL connection gets initialized the defaults in the globals will be overwritten anyway...

[ninsbl]

Solved as part of #7672, but again thanks for the effort. We continue the discussion on #7670