fix(context): use cwd basename for project name in monorepo subdirectories (closes #2882)

[rodboev]

Summary

In a git monorepo, getProjectName() always returns the repo root basename, so every package shares the same project name. Observations from packages/api sessions are stored under monorepo, mixed with observations from packages/web and every other subdirectory. This PR makes getProjectName() use the cwd basename when the working directory is a subdirectory of the git root (the monorepo case), while preserving existing behavior for single-repo roots and non-git directories.

Closes #2882

Why

src/utils/project-name.ts:47 sets nameSource = repoRoot ?? expanded. When cwd is /work/monorepo/packages/api, findGitRepoRoot() returns /work/monorepo, so nameSource is always the root and path.basename(nameSource) = monorepo. PR #2663 introduced this for worktree stability, but getProjectContext() already handles worktrees separately via detectWorktree(). Monorepo subdirectories should not share a project name.

The fix adds a samePath() helper (using realpathSync + path.resolve() for canonicalization, case-insensitive on Windows, with a fallback to resolve-only when realpathSync throws) and changes the nameSource logic:

const nameSource = repoRoot && samePath(expanded, repoRoot)
  ? repoRoot
  : expanded;

When cwd equals the git root, samePath returns true and behavior is unchanged. When cwd is a subdirectory, samePath returns false and expanded (the cwd) provides the basename. Non-git directories and drive roots are unaffected. Symlinked repo roots are handled correctly because realpathSync resolves both sides before comparing.

Scope

This PR does not change storage key format, observation schema, or worker protocol. Worktree composite naming (parent/leaf via detectWorktree()) is unchanged. The drive-root and unknown-project fallback paths are unchanged.

Upgrade Impact

Existing monorepo users: Observations stored before this change are keyed by the repo-root basename (e.g., monorepo). After upgrade, new sessions in a monorepo subdirectory (e.g., packages/api) will use the package basename (api) as the project key. Existing observations under the old root-level key remain in storage but will not be returned for the subdirectory cwd. This is the intended behavior: the old mixed-project key was the bug. Users who need continuity can manually reference their stored memories under the old project name or reset their project context.

Note: getProjectContext().allProjects returns only [cwdProjectName] for non-worktree subdirectory cwds — it does not include the parent repo-root name. If a future session needs to query observations stored under both the old root-level key and the new package-level key during migration, callers would need to add the repo-root name to allProjects for that case.

Single-repo users: No change. When cwd equals the git root, samePath returns true and nameSource remains the git root — identical to the previous behavior.

Verification

• bun test tests/utils/project-name.test.ts — existing tests pass; updated nested-dir test passes; new monorepo package test passes
• npm run build — clean
• npm run lint:hook-io && npm run lint:spawn-env && npm run strip-comments:check — clean

Closes #2882

[greptile-apps]

Greptile Summary

This PR updates project-name selection for monorepo package directories. The main changes are:

• Walks upward from the cwd to find the nearest package.json under the git root.
• Uses that package directory basename for sessions inside monorepo packages.
• Keeps linked worktree roots and normal repo-root naming behavior unchanged.
• Adds coverage for package subdirectories sharing the package project name.

Confidence Score: 4/5

The change is narrowly scoped to project-name selection and includes targeted test coverage for the affected monorepo behavior.

No blocking issues were identified in the changed files, and the implementation preserves the existing root and worktree behavior described by the change.

T-Rex Logs

What T-Rex did

• Ran baseline checks for apiPackageProjectName, webPackageProjectName, and apiSrcProjectName; all three reported monorepo and the process exited with code 0.
• Ran head-state checks for the same packages; apiPackageProjectName returned 'api', webPackageProjectName returned 'web', and apiSrcProjectName returned 'api', with preservation checks passing and exit code 0.

_{Ran code and verified through T-Rex}

_{Reviews (3): Last reviewed commit: "fix(context): walk upward to package.jso..." | Re-trigger Greptile}