refactor[next]: give the build caches one home too

[havogt]

Top of the stack: #2769 (layout names) → #2768 (cache manager CLI) → this.

Why

#2769 gave the two translation caches one home. The build caches were left
loose in the cache base — one folder per compiled program variant, sitting
directly next to translation_cache/:

.gt4py_cache/
├── translation_cache/{dace,gtfn}/        <- a fixed directory
├── lap_program_pyext_<fp>_<version>/     <- ... next to an unbounded set of
├── laplap_program_pyext_<fp>_<version>/     program folders
└── compile_commands_cache_..._pyext_.../

So the base mixed the two, and nothing in the listing said which entry was
which kind of cache. That is also what invites "is the DaCe build directory
inside translation_cache?", the question that started #2769.

What

.gt4py_cache/
├── translation_cache/{dace,gtfn}/
└── build_cache/<program>_pyext_<fingerprint>_<version>/

The base now holds exactly the two kinds of cache gt4py.next keeps, each named
for what it is.

No <backend> level here, deliberately. Which backend produced a build
folder is not knowable where the folder is named: get_cache_folder is reached
from otf/compilation/ and its build systems, which are generic over the source
language rather than aware of backends, so a backend level would mean either
threading a name through that layer or mapping language→backend. The fingerprint
already keeps variants apart, so the flat set is correct — only its location
changes.

dace_determinism.py scans that directory and so far learned only the
folder-name pattern from the gt4py under test. Its probe now returns the
directory name too, rather than gaining a second hardcoded literal, so a
gt4py-side move of the build cache surfaces as a fetch error instead of as "no
programs observed". The stub interpreters in its tests answer with a different
directory name than gt4py's own, which is what proves nothing is hardcoded.

Migration

Not migrated — and these are the large caches. They are already discarded on any
change of BUILD_CACHE_VERSION_ID (every gt4py version bump, and every commit
for an editable install), so orphaned build folders are the normal state of this
cache; the stale directories can simply be removed.

Verification

• Compiled a program with both backends into a fresh cache and confirmed the
  resulting tree, then read it back through gt4py-next-cache path and
  list --by-program.
• Ran dace_determinism check against real caches in the new layout: it reports
  3 in run1, 3 in run2, i.e. it locates the program folders one level down.
  Before this change that scan returns 0 and raises NoProgramsObservedError.
• scripts/test python: 46 passed. tests/next_tests/unit_tests/test_gt_cache_manager.py
  and otf_tests: 137 passed. Hooks clean.
• The delete guard in the CLI was tightened with the move: a folder with a valid
  build-folder name but the wrong parent is still refused.