refactor: move projectDir resolution into QuartoProjectHelper

[posit-connect-projects]

Summary

Follows up on review feedback from #4048 (comment) — QuartoProjectHelper now handles resolving relative projectDir values internally via a new optional rootDir constructor parameter, instead of requiring callers to resolve paths before constructing the helper.

• Added optional rootDir parameter to QuartoProjectHelper constructor that resolves projectDir against rootDir using path.resolve()
• Updated renderQuartoContent() to accept and forward rootDir
• Updated homeView.ts to pass the workspace root as rootDir instead of resolving the path manually

Note: This PR will have a small merge conflict with #4048 in homeView.ts (both PRs touch the renderContent method). Whichever merges second will need a trivial conflict resolution.

Test plan

• Unit tests for rootDir resolution in quartoProjectHelper.test.ts (relative, nested relative, absolute, omitted)
• Smoke tests for rootDir with real filesystem in quartoProjectHelper.smoke.test.ts (path resolution, _quarto.yml detection, command construction)
• Existing tests continue to pass (28 passed, 2 skipped)
• Lint passes

🤖 Generated with Claude Code

[zackverham]

@claude is there any manual testing we can do to smoke test this change?

[posit-connect-projects]

Claude finished @zackverham's task in 53s —— View job

---

Manual Testing for projectDir Resolution

• Analyze PR changes
• Provide manual testing guidance

Yes — here's a manual smoke test plan for this change. The core behavior to verify is that Quarto rendering works correctly when projectDir in the deployment config is a relative path (which is the common case, e.g. ".").

---

Prerequisites

• Quarto installed (quarto --version)
• The extension built from this branch (F5 debug launch from extensions/vscode/)

Test 1: Basic Quarto document render (relative projectDir = ".")

1. Open a workspace folder containing a simple .qmd file (e.g. index.qmd with format: html)
2. Create a deployment config (.posit/publish/something.toml) pointing to that file — projectDir should be "." (the default)
3. Trigger the "Render" action from the Publisher sidebar
4. Expected: Quarto renders successfully, notification says "Finished rendering Quarto content"

Test 2: Quarto project render (relative projectDir with _quarto.yml)

1. Open a workspace with a _quarto.yml project (website type is fine)
2. Ensure the deployment config has projectDir = "."
3. Trigger render
4. Expected: Runs quarto render "<absolute-workspace-path>" (project mode), not quarto render "<absolute-path>/index.qmd" (document mode). You can verify this by watching the terminal output or checking for _site/ output.

Test 3: Nested project directory

1. Create a workspace with a Quarto project in a subdirectory (e.g. reports/quarterly/)
2. Set projectDir = "reports/quarterly" in the deployment config
3. Trigger render
4. Expected: Renders from the correct subdirectory. The resolved path should be <workspace-root>/reports/quarterly.

Test 4: Multi-root workspace (if applicable)

1. Open a multi-root workspace where the Quarto content is not in the first folder
2. Trigger render
3. Expected: Render uses the correct workspace root for resolution, not the first folder or extension host's cwd.

---

What could go wrong

The key bug this PR guards against: if rootDir isn't passed correctly, a relative projectDir like "." would resolve against the extension host's cwd (which is unpredictable) rather than the workspace root. Symptoms would be:

• _quarto.yml not detected → falls through to single-document render instead of project render
• Render command targeting the wrong directory

The automated tests (28 passing + the new rootDir suite) cover the logic thoroughly, so manual testing is mainly a confidence check that the wiring through homeView.ts → renders.ts → QuartoProjectHelper works end-to-end in a real VSCode session.

---