fix(tauri): prefer bundled server entry in release

[pascalandr]

Why

When running the Tauri release executable from target/release, the app should start the server bundle that was packaged next to the executable:

target/release/resources/server/dist/bin.js

Before this change, resolve_prod_entry() checked the workspace build first:

packages/server/dist/bin.js

That can make a release run depend on the local checkout instead of the packaged resources. It also makes rebuild/runtime checks misleading, because the exe may appear to work while using files outside the release bundle.

What Changed

• Check bundled release resource paths first when resolving the production server entry.
• Keep the workspace packages/server/dist/bin.js path as a fallback.

Validation

• Verified the change is limited to production entry resolution in cli_manager.rs.
• This was discovered while launching the rebuilt Tauri release executable and checking that the spawned Node process used target/release/resources/server/dist.

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Understood request: perform a strict gatekeeper review of the latest PR state for regressions, implementation quality, and better alternatives. I treated this as review-only and did not change code.

Gatekeeper Result

No blocking findings found.

The PR is tightly scoped to packages/tauri-app/src-tauri/src/cli_manager.rs and changes resolve_prod_entry() so bundled release resource paths are checked before the workspace fallback. That directly addresses the reported release-runtime hazard where target/release could appear healthy while actually spawning packages/server/dist/bin.js from the checkout.

Regression Review

• The candidate order now prefers the release bundle before workspace_root()/packages/server/dist/bin.js, which is the correct behavior for production resolution.
• The workspace fallback is still preserved, so local/dev-adjacent scenarios that relied on the previous fallback are not removed.
• The change does not affect resolve_dev_entry() or the dev tsx path resolution.
• The first_existing() behavior remains unchanged, so the only behavioral change is candidate priority.

Better Implementation Notes

• Non-blocking: resolve_prod_entry(_app: &AppHandle) still ignores AppHandle and hardcodes platform resource candidates relative to current_exe(). Longer term, using Tauri's resource path APIs would be less brittle than maintaining platform-specific guesses manually.
• Non-blocking: this path-ordering behavior would benefit from a small unit-testable helper that builds the candidate list, but the current patch is intentionally minimal and does not expand the surface area.

Validation Performed

• Reviewed the full PR diff against origin/dev; only cli_manager.rs changes in the PR.
• Ran git diff --check origin/dev...HEAD; passed with no whitespace errors.
• Attempted cargo test --manifest-path packages/tauri-app/src-tauri/Cargo.toml; blocked before test execution by the existing Tauri config requirement: frontendDist is set to "resources/ui-loading" but that generated path is absent in this checkout.

Residual Risk

• I could not execute the Rust test target due to the missing generated UI resource directory.
• The touched file is already oversized at approximately 1,357 lines; this PR does not make that worse materially, but future changes in this area should consider extracting entry-resolution logic into a smaller testable module.

--
Yours,
CodeNomadBot