Prompt for content type when detection can't determine one

[nealrichardson]

Summary

When Publisher can't detect a content type for an entrypoint, it now prompts you to pick one from the list of valid content types instead of silently writing type = "unknown" to the config. The chosen type is treated as if it had been detected automatically, including filling in the required [python]/[r]/[quarto] sections.

Closes #2833
Closes #2666

Test plan

• tsc --noEmit
• eslint (project-wide, zero warnings)
• vitest run (full suite, 1991 tests)
• Manual: create a deployment for an entrypoint Publisher can't detect (e.g. a FastAPI app with no import fastapi) and confirm the content-type picker appears and produces a valid config

[posit-connect-projects]

Claude finished @nealrichardson's task in 1m 31s —— View job

---

Code Review Complete

• Read and analyze changed files
• Review extensions/vscode/src/inspect/index.ts changes
• Review extensions/vscode/src/inspect/normalize.ts changes
• Review extensions/vscode/src/multiStepInputs/newDeployment.ts changes
• Review test coverage in extensions/vscode/src/inspect/index.test.ts
• Check for bugs, security issues, and best practices
• Post inline comments for findings

---

Overall: This PR looks good to merge. The implementation is clean, well-documented, and follows existing patterns in the codebase.

Summary of Changes

1. New inspectManualContentType function (index.ts) - Creates a configuration for a user-selected content type when detection returns UNKNOWN. It correctly fills in the required [python], [r], or [quarto] sections based on the content type.

2. Exported helper functions (normalize.ts) - isPythonContentType, isRRequiredContentType, and isQuartoContentType were refactored from a private function to module-level constants + exported functions for reuse.

3. Manual content type picker flow (newDeployment.ts) - When detection returns a single UNKNOWN result, the UI now prompts the user to select from all valid content types instead of silently writing type = "unknown".

4. Good test coverage - Tests verify Python, R, Quarto, and HTML content types are handled correctly, including the projectDir field.

Strengths

• Clean separation of concerns: The inspectManualContentType function in the inspect module handles building the config, while the UI code in newDeployment.ts handles the user interaction.

• Follows existing patterns: The new code reuses normalizeConfig and toConfigurationDetails, ensuring manual selections behave identically to auto-detected ones.

• Good UX: The placeholder text clearly explains why the user is being prompted ("Publisher could not automatically determine the content type...").

• The follow-up fix (commit 79c2491) correctly addresses projectDir being preserved when manually picking a content type.

Minor Observations (not blocking)

• The lastInspectionContext pattern works correctly for the current flow, but if future changes add additional paths to getManualContentTypeQuickPicks, it could return an empty array silently. The current implementation is fine since getConfigurationInspectionQuickPicks is always called first.

• The CHANGELOG entry is well-written and correctly references issue numbers.

No bugs, security issues, or code quality concerns found. Approving this PR.

[nealrichardson]

I tried this locally, and it works, but the contents of the menu, the list of options of app modes, needs some work, so let me iterate on this some more.