Remove duplicate lstk install detection

[gtsiolis]

Motivation

Multiple lstk binaries on PATH are increasingly legitimate: users may install the CLI through package or version managers, and tools such as the VS Code extension are expected to bundle their own copy. Duplicate-install detection cannot reliably distinguish those intentional copies from stale installations, which produces false positives and verbose warnings without useful remediation.

Linear decision record: DEVX-1015.

Solution

• Stop scanning PATH from both lstk update and the startup update notification.
• Remove the duplicate-install scanner and its Unix and Windows executable probes.
• Remove the dedicated plain, JSON, and TUI warning event and rendering.
• Remove the associated unit and integration tests.
• Keep detection of the active executable install method, which is still required to choose the Homebrew, npm, or binary updater.

Docs

Docs impact

No external documentation changes are needed. The internal architecture guidance no longer advertises duplicate-install detection.

Review

Human review advised: this removes existing user-facing warning behavior from both the update and startup paths. The implementation is a focused deletion following reviewer feedback.

Validated with:

• make build
• make test (1,621 tests passed)
• make test-integration RUN=TestUpdateBinaryMockGitHubChecksumMismatch
• Pre-commit secret scan
• git diff --check

Co-Authored-By: Claude noreply@anthropic.com

Closes DEVX-1015

[gtsiolis]

Second attempt to improve #408.

@skyrpex I'm curious what you think sice you added this.

[gtsiolis]

Added this because I kept seeing this warning with breaking lines on my terminal.

[skyrpex]

I remember somebody (maybe Peter?) suggesting to remove the whole dupe detection altogether, which I'd be in favor of. Should we then just remove detection?

[gtsiolis]

I'm also in favor of removing this low-impact check.

Re-purposed PR in b00f6f5. Could you take another look?

[skyrpex]

Excellent, only deletions :party:

[peter-smith-phd]

@gtsiolis, what's the Linear issue associated with this PR? I think we should have that issue in backlog status while we discuss the solution, then when the issue moves to Todo, we can be confident that we've agreed on the correct solution. Thanks.

[peter-smith-phd]

Need a valid Linear issue number in Todo state.

[gtsiolis]

Thanks, @peter-smith-phd, this was already tracked in DEVX-1015.

I’ve updated the issue with additional context and linked it from the PR.

Please add any remaining concerns or risks to the issue or here. Otherwise, I think we can merge this to resolve the user-facing friction and keep the feedback loop short, since this is a low-risk removal that doesn’t affect core CLI functionality, and we can iterate if needed.

[gtsiolis]

Superseded by #460, which carries the identical scoped change from a branch in localstack/lstk so the integration workflow can access repository secrets. The original discussion remains here for context.

[peter-smith-phd]

and we can iterate if needed.

I'd prefer not to "iterate" too much. We have enough experience in this company to know what the correct behaviour should be, and as long as we talk about issues upfront, we won't find ourselves adding features, then removing them later. Enterprise customers expect stability 😄