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 the 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 a Ruby gem) and wrong injection targets (e.g. appending Ruby init into a Node index.js).

Shared resolution logic: entry-point fallbacks and search candidates live in one sdkEntryPoints table, with EntryPointFor and PackageManagerFor used by both filesystem detection and the override path so they stay aligned.

UI: manual-init instructions use addCodeTo so snippet-only SDKs don’t show an empty “add to” path on the done screen.

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