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.

BEFORE	AFTER

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

[peter-smith-phd]

Human review advised

This seems to be a Claude-generated message. @gtsiolis, can you please update the PR description to indicate that you personally have reviewed the code, and are confident in its correctness. Also, please list the additional tests that you did to validate it.

We have a "no second reviewer" policy, but we still expect the "first reviewer" (you) to ensure correctness/quality.

[gtsiolis]

Thanks, Peter! 🙏

You’re right, this is generated by Claude, following instructions we configured. The Review section was introduced in #405 and refined in #435, as part of the /create-pr skill. Its purpose is to provide a consistent risk signal about whether an additional human reviewer would be valuable. That distinction may need clearer wording. 💭

Author self-review is separate from that signal, and I expect it to be the baseline for every PR from every author. If that expectation is not being met consistently, we should raise it internally. I've reviewed this PR and feel confident in its correctness. I've also listed tests and BEFORE/AFTER screenshots. ✔️

I don’t think adding a self-review indication to every PR is the right mechanism, but I’m happy to discuss this further. ➕

Going to merge this because the identical changes were reviewed and approved in #455 (review), and CI is green. 🟢

[peter-smith-phd]

Thanks for clarifying, @gtsiolis. However, when I see names like "Sergio" showing up in a PR description, it's only right that I question whether a human actually read the PR.

Going to merge this because the identical changes were reviewed and approved

This indicates to me that a second human might have read the PR, but they also might have assumed that the first human had already reviewed it carefully.

I've reviewed this PR and feel confident in its correctness

Thank you, that's encouraging 🙂