Fix RealDataTestsBase cross-worktree test collisions

[johnml1135]

Summary

• RealDataTestsBase (backing RenderBaselineTests, RenderBenchmarkTestsBase, and subclasses) resolved its scratch test-project directory via FwDirectoryFinder.ProjectsDirectory, a per-machine registry value that's correct for the shipping app (one shared Projects folder machine-wide) but means every git worktree of this repo collides on the same physical integration_test_data folder when running these tests.
• Symptom: System.InvalidOperationException: Refusing to delete '...\integration_test_data' because the test sentinel file '.fieldworks-real-data-test-project' is missing — one worktree's test run deletes/rewrites another's project mid-run.
• Fix (scoped entirely to this test fixture, FwDirectoryFinder's production API is untouched):
  1. DbDirectory() now resolves under this checkout's own SourceDirectory/../DistFiles/Projects, matching the pattern already used by other real-cache test fixtures in this repo (ConfiguredXHTMLGeneratorTests, RecordListTests, etc.).
  2. The project name is suffixed with a short hash of the worktree's SourceDirectory, because FwNewLangProjectModel.CheckForUniqueProjectName — correct, unrelated production logic for the real "New Project" wizard — checks name uniqueness against the shared ProjectsDirectory regardless of where this fixture's files live, so a fixed name still collided across worktrees. The suffix is stable within a worktree (preserving the mutex-guarded "reusable project" perf intent) but unique across worktrees.

Found and fixed while running CI locally as part of an unrelated PR #964 review — see that PR's PR_964_review.md §15 for the full investigation trail.

Test plan

• RenderBaselineTests + RealDataTestsBaseCleanupTests (9 tests): went from 8/9 failing with the collision error to 9/9 passing.
• Full ./test.ps1 CI-equivalent run

🤖 Generated with Claude Code

---

This change is 

[github-actions]

NUnit Tests

    1 files  ±0      1 suites  ±0   10m 46s ⏱️ +7s
4 299 tests ±0  4 226 ✅ ±0  73 💤 ±0  0 ❌ ±0 
4 308 runs  ±0  4 235 ✅ ±0  73 💤 ±0  0 ❌ ±0 

Results for commit 4ad271e. ± Comparison against base commit 4509530.

♻️ This comment has been updated with latest results.

[jasonleenaylor]

@jasonleenaylor reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on johnml1135).

[jasonleenaylor]

A commit comment that contains all the comments also present in the code is a bit much. Please make sure we commit a much more results focused comment rather than details of the solution and maybe shorten the code comments as well.

@jasonleenaylor made 2 comments.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on johnml1135).

---

Src/Common/RootSite/RootSiteTests/RealDataTestsBase.cs line 169 at r1 (raw file):

			// delete or rewrite another's mid-run). Anchor to this checkout's own DistFiles/Projects
			// instead - the same SourceDirectory-derived, registry-free pattern already used by other
			// real-cache test fixtures in this repo (e.g. ConfiguredXHTMLGeneratorTests, RecordListTests).

This comment is awefully long and wordy, wouldn't mind a pass at tightening it up.

[johnml1135]

Cleaned up comments to be simpler.

[johnml1135]

Code review (verified against the code at the PR head)

HIGH — DbDirectory()'s worktree-local repoint doesn't match where the project actually gets validated/created, so the fix doesn't close the collision it targets

RealDataTestsBase.cs:152-158 repoints DbDirectory() to a worktree-local path (Path.GetDirectoryName(FwDirectoryFinder.SourceDirectory)\DistFiles\Projects) instead of FwDirectoryFinder.ProjectsDirectory. But EnsureSafeProjectDirectory (line 346-353+), which every actual-creation path (GetProjectDirectory, called from TestSetup at line 82 right after CreateNewLangProj) is validated against, still hardcodes the expected directory as:

var expectedProjectDirectory = NormalizePath(
    Path.Combine(FwDirectoryFinder.ProjectsDirectory, ReusableProjectName));

FwDirectoryFinder.ProjectsDirectory resolves from a machine-wide registry value (or %CommonApplicationData%\SIL\FieldWorks\Projects by default) — it can't be per-worktree. So the actual project created by CreateNewLangProj still lands under the shared, machine-wide ProjectsDirectory (that's what the validation in EnsureSafeProjectDirectory requires it to do, or GetProjectDirectory throws). The new worktree-suffixed ReusableProjectName (from the other hunk) does prevent same-name collisions across worktrees at that shared location, so that part is genuinely useful. But DbDirectory()'s worktree-local rerouting is now dead for the creation path and only affects the pre-create cleanup call at line 51 (m_projectDirectory = DbDirectory(m_dbName); ... DeleteProjectDirectory(m_projectDirectory) before CreateNewLangProj runs).

Concretely: if a prior test run crashes mid-setup and leaves an orphaned project directory at the real location (ProjectsDirectory\integration_test_data_<hash>), the next run's pre-create cleanup checks the wrong (worktree-local, never-populated) path and won't find or delete it — CreateNewLangProj then runs against a dirty leftover directory instead of a clean one.

Suggest either dropping the DbDirectory() change (the worktree suffix on ReusableProjectName already does the collision-avoidance work) or making EnsureSafeProjectDirectory's expected path consistent with DbDirectory()'s.

_{Reviewed with Claude Code; findings verified against the code at the PR head. No code changed.}

[johnml1135]

Fixed in 19dc4a3. Traced it further: CreateNewLangProj → LcmCache.CreateNewLangProj always creates the project under dirs.ProjectsDirectory (ILcmDirectories.ProjectsDirectory, which is just FwDirectoryFinder.ProjectsDirectory) — it can't be redirected to a worktree-local path without deeper plumbing than this class has. So EnsureSafeProjectDirectory's hardcoded expectation was actually the correct/necessary one; DbDirectory() was the one that had drifted.

Reverted DbDirectory() to FwDirectoryFinder.ProjectsDirectory. The collision-avoidance this PR is actually after still holds: ReusableProjectName's worktree-hash suffix gives each worktree a distinct subdirectory name (and mutex name) under that same shared directory, so parallel worktrees no longer collide — and now the pre-create cleanup path checks the same location the project actually gets created/validated against.