ci(preview-build): select latest preview branch

[kangfenmao]

What this PR does

Before this PR:
The v2 daily preview build always checked out the hard-coded v2 branch and patched preview app identity values before building.

After this PR:
The workflow discovers the latest preview/v* branch by semantic version, builds that exact commit, patches package.json with the selected preview version before packaging, and only patches the preview product name.

Fixes #N/A

Why we need it and why it was done in this way

The following tradeoffs were made:
The branch/version resolution is implemented directly in the workflow so the metadata job can run before dependencies are installed and all platform builds can reuse the same selected commit.

The following alternatives were considered:
Using a fixed v2 branch was kept out because preview artifacts need to follow the newest preview release branch. Installing project dependencies just to use a semver helper was avoided to keep metadata resolution lightweight.

Links to places where the discussion took place: N/A

Breaking changes

None.

If this PR introduces breaking changes, please describe the changes and the impact on users.

Special notes for your reviewer

This only changes the preview build workflow. It does not change committed package.json or electron-builder.yml; those files are patched in the CI workspace before packaging.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

NONE