Issue #8012 : Resolve marketplace env file paths against the project home

[vbhanuchander-lang]

Fixes #8012

The defect

The env file configured on a lifecycle environment (Project/Environment dialog → Plugins tab) is documented as a reference that "may contain variables", but nothing anchored it to the project. Two independent halves of the same problem:

1. Lookup. resolveEnvFile() expanded variables and handed the result to VFS. HopVfs.resolveWith() turns a name with no scheme into new File(name).getAbsolutePath() — i.e. it anchors at user.dir, which for a launched Hop GUI is the Hop installation directory. So config/hop-env.yaml configured on an environment was looked up under the install, never under the project, and the check silently found nothing.

2. The chooser. The Browse button on that tab called BaseDialog.presentFileDialog(...) with no starting FileObject. For an open dialog that is the only thing that sets the start location (BaseDialog only calls setFileName/setFilterPath when a FileObject is supplied), so the browser opened at its own default with no relation to the file already configured — which is what the report shows. HopInstallSpecEditor.presentSpecFileDialog() already seeds a starting file since #8059; this call site was not updated with it.

3. LifecycleEnvironmentDialog builds the AttributesContext it hands to plugin tabs but never called setProjectHome(...), so a tab had no project home to anchor against even if it wanted to.

The fix

HopInstallSpecFiles.resolveInProject(filename, variables, projectHome) expands variables and, only if the result is still relative, anchors it at the project home (falling back to the PROJECT_HOME variable). Absolute POSIX paths, Windows drive letters, UNC paths and VFS URLs (s3://…, file://…) are returned untouched, as is anything relative when no absolute project home is known — that keeps today's behaviour rather than inventing a base.

Wired into the runtime check and into both buttons on the tab. Browse and Edit now start at the configured spec file when it resolves, and at the project home otherwise.

One detail worth calling out: the reference the user typed wins when it already resolves. Anchoring is only attempted as a fallback. Without that, opening ${PROJECT_HOME}/hop-env.yaml in the editor and saving would write the expanded absolute path back into the field, quietly destroying the portable reference.

Tests

14 new tests in HopInstallSpecFilesResolveInProjectTest. 7 of them fail if resolveInProject is reduced to today's resolve, including relativeReferenceIsOnlyFoundOnceAnchoredAtTheProject, which writes a real config/hop-env.yaml under a temp project home and asserts through HopInstallSpecFiles.exists() that the reference is only found once anchored — that is the reported bug end to end, not just the helper's own contract. The other 7 are the guards that absolute/UNC/drive/VFS references are never rewritten, and they pass either way by design.

Verified locally on JDK 21: hop-misc-marketplace 252 tests, hop-misc-projects 123 tests, 0 failures. spotless:check and apache-rat:check clean on both modules.

Not changed

MarketplaceRepositoriesPanel's import/export choosers have the same missing start location, but those handle repository definitions rather than the environment spec file and are outside what #8012 reports. Happy to fold them in if you would prefer one pass over all of them.