fix(core): prefer current repo when resolving amber home path

[carloea2]

What changes were proposed in this PR?

This PR fixes an issue in amberHomePath resolution where the previous implementation could select the wrong repo when multiple sibling directories under the same parent satisfied isAmberHomePath(...).

texera/amber/src/main/scala/org/apache/texera/amber/engine/common/Utils.scala

Lines 39 to 59 in ac909a0

	lazy val amberHomePath: Path = {
	val currentWorkingDirectory = Paths.get(".").toRealPath()
	// check if the current directory is the amber home path
	if (isAmberHomePath(currentWorkingDirectory)) {
	currentWorkingDirectory
	} else {
	// from current path's parent directory, search its children to find amber home path
	// current max depth is set to 2 (current path's siblings and direct children)
	val searchChildren = Files
	.walk(currentWorkingDirectory.getParent, 2)
	.filter((path: Path) => isAmberHomePath(path))
	.findAny
	if (searchChildren.isPresent) {
	searchChildren.get
	} else {
	throw new RuntimeException(
	"Finding texera home path failed. Current working directory is " + currentWorkingDirectory
	)
	}
	}
	}

Previously, if the current working directory was not itself recognized as the Amber home path, the code would walk the parent directory and return findAny() from matching paths. In environments with multiple Texera/Amber repos under the same parent, this could resolve to an unrelated sibling repo instead of the repo the process was launched from.

This PR changes the logic to:

• keep returning the current working directory immediately when it is already a valid Amber home path
• guard against searching from filesystem root when there is no parent
• prefer the closest valid match associated with the current working directory
• fall back to any valid match only when no closer candidate is found
• normalize returned paths with toRealPath()
• close Files.walk(...) safely using Using.resource(...)

This makes Amber home path detection more deterministic and prevents accidentally selecting the wrong engine/repo in multi-repo local setups.

Any related issues, documentation, discussions?

Closes #4262

How was this PR tested?

Manually tested with a local directory layout where multiple sibling repos satisfy isAmberHomePath(...).

Example setup:

E:\texera\
  ├─ texera\
  └─ a\

Was this PR authored or co-authored using generative AI tooling?

No.

[carloea2]

@chenlica Can you assign a reviewer? Thanks.

[chenlica]

@aglinxinyuan @Xiao-zhen-Liu Please review this PR.

[Copilot]

Pull request overview

Improves Utils.amberHomePath resolution to be more deterministic in environments where multiple sibling repositories may contain an amber/ directory, reducing the chance of selecting the wrong repo when launched from a non-amber working directory.

Changes:

• Adds a two-pass search strategy to prefer a “closest” match before falling back to any match.
• Adds safeguards for filesystem-root cases and normalizes returned paths via toRealPath().
• Ensances resource safety by closing Files.walk(...) via Using.resource(...).

---

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

[carloea2]

Just curious, who requested copilot review?

[aglinxinyuan]

Just curious, who requested copilot review?

I requested it. Please address the comments from Copilot before I have a pass.

[carloea2]

@aglinxinyuan done.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

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

[carloea2]

I prefer the current way since the match is deeper, I think both options can be, it depends in the design decision. @aglinxinyuan what is your preference?

[aglinxinyuan]

Could you provide an example of a user who would prefer the deeper one instead of the closer one? From my perspective, if I run a command in the current working directory, I would expect the binary in the closest folder to be used rather than the one in the deepest folder.

[aglinxinyuan]

LGTM! Please address Copilot comments.

I only tested on local. Since it might affect our servers, we might need to test it on the server before merging it. @carloea2, please coordinate with @aicam to test this change on the server environment or Ubuntu.