fix(setup): re-derive entry point and package manager on SDK override

[ffantl-ld]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

REL-15430 — found in the ldcli setup bug bash. Also closes known issues #9 (package manager not re-derived) and #8 (empty file path on the final screen) from the bug bash page.

Stacked on #781, which targets setup-ld (#776) and touches the same files.

Describe the solution you've provided

• Re-derive the entry point and the package manager for the chosen SDK when the user overrides detection, instead of substituting that SDK's bare default in $PWD. Previously a project whose entry file was src/index.js got a second index.js created beside it, and the package manager still described the language detection guessed first — so a Ruby install never ran bundle add.
• Move the entry-point candidate lists into one table that both detection and the override path read, so the two cannot disagree about where code goes. Framework-specific layouts (Next.js, React) stay inline, since an override clears the detected framework.
• Omit the destination from the "add this initialization code" line when the SDK only shows a snippet and has no entry point, rather than printing an empty path.

Describe alternatives you've considered

• Keeping the per-SDK default and only fixing the file-exists check. Rejected: the default is a single filename, so it still misses an entry point that lives anywhere other than the repo root.
• Preserving the detected package manager, which the previous test asserted as intended behaviour. Rejected: pnpm cannot install a gem, and carrying it forward is what suppressed bundle add.

Additional context

TestWizard_OverrideSDK_DoesNotReuseDetectedEntryPoint asserted that the package manager survives an override, which encoded known issue #9 as expected behaviour. Its expectation is updated to the re-derived value.

Testing approaches

• go test ./... passes.
• Added unit coverage for EntryPointFor (finds an existing file, suggests a fallback, empty for snippet-only SDKs) and PackageManagerFor (Bundler vs bare gem, node lockfile, uv, manual-install SDKs).
• Added a wizard test reproducing the reported shape: a project with only src/index.js, overridden to node-server, now resolves to the existing file rather than creating a sibling.
• Confirmed with a built binary that setup detect reports src/index.js for that project shape. The override itself is TUI-only and is covered by the model-level test rather than by hand.

---

Note

Overview
When someone overrides auto-detected SDK in ldcli setup, the wizard now re-derives entry point and package manager for the chosen SDK instead of keeping values from the first detection. That stops wrong installs (e.g. pnpm for Ruby) and wrong injection targets (e.g. appending Ruby init into a Node index.js).

Shared detection logic: Entry-point candidate lists for Node, Python, and Ruby live in a single sdkEntryPoints table used by both filesystem detection and the override path, so detection and manual SDK choice agree on where code goes.

UI: Manual-setup messages use addCodeTo so snippet-only SDKs don’t show an empty “add to” path.

Tests cover override scenarios (src/index.js resolution, package manager re-derivation) and the new EntryPointFor / PackageManagerFor helpers.

^{Reviewed by Cursor Bugbot for commit b94d3d1. Bugbot is set up for automated code reviews on this repo. Configure here.}