fix: prefer local repo build over stale cached frontend

[Selene29]

Summary

• _start_frontend() checked the cached download (~/.repowise/web/) before the local repo build, so a stale cached version was always served even when a newer local build existed
• Swaps the priority: local repo builds are now preferred, with the cached download as a fallback for pip-installed users

Test plan

• Run repowise serve from a repo checkout that has a local .next/standalone build
• Verify the local build is served (not the cached ~/.repowise/web/ version)
• Verify pip-installed users without a local build still get the cached download

[RaghavChamadiya]

This is correct. The local build should always win over a potentially stale cache, and the old ordering was clearly backwards.

One quick confirmation: is there any scenario where a pip-installed user has a local .next/standalone build on their machine? If not, this is purely a developer-mode fix with zero impact on pip users, and the cached fallback still works for them as before. Just want to confirm before merging.

[Selene29]

Correct. No impact on pip users. _find_local_web() walks up from file (which resolves to site-packages/ for pip installs) and cwd, looking for packages/web/package.json. Neither path will match unless you're in the repo checkout itself. So for pip users, _find_local_web() returns None and the cached download fallback works exactly as before. This only affects editable installs / running from source. That is at least my understanding :)