fix: restore Go installation for v2 releases

[mvanhorn]

Testing

• From the repository root, the module reports github.com/kunchenguid/treehouse/v2, all packages resolve under that prefix, and the existing full Go test/build matrix continues to pass on Linux, macOS, and Windows.
• The regression test fails when go.mod loses the /v2 suffix or when any production or test Go source imports github.com/kunchenguid/treehouse/... without /v2.
• The README documents go install github.com/kunchenguid/treehouse/v2@latest, while clone URLs, GitHub release/update endpoints, Nix references, and installer repository identifiers remain unsuffixed.
• After a maintainer publishes a corrected v2 tag, installing that tag through the /v2 module path succeeds; the release/tag verification remains an external post-merge check because an unpublished tag cannot be exercised in repository tests.

What Changed

Change the module declaration to github.com/kunchenguid/treehouse/v2 and migrate every Go self-import to that canonical prefix, including the import used by internal/pool/pool_test.go, so all packages remain within one valid v2 module. Update only the README's Go installation command to use the /v2 path; repository URLs used for cloning, releases, badges, Nix inputs, install scripts, and updater API calls continue to identify the unchanged GitHub repository and must not gain the module suffix. Add a focused root-level regression test that derives the declared module path from go.mod and verifies it is the expected v2 path and that repository Go files contain no legacy unsuffixed self-imports, without introducing a production-only test seam.

Why

Treehouse's v2 tags still declare the unsuffixed github.com/kunchenguid/treehouse module path, violating Go's semantic import versioning rule for major versions greater than one. Consequently, both explicit v2 installation forms fail, while the README's @latest command silently resolves to v1.8.0 instead of a current release. The report includes reproducible failures for v2.0.0, and a follow-up confirms the defect persists through v2.1.1. The issue is open and unassigned, with no competing or prior closed-unmerged pull requests in the supplied evidence.

Fixes #62