🤖 ci: pin the Junie action to its newest release, v1.7.4

Checked against the action repo itself rather than assumed: git ls-remote
shows v1.7.4 is the newest release tag and the moving v1 tag points at the
same commit (c2ae82f), so this changes which ref is named, not which code
runs — today. What it buys is that the version running stays the version
that was reviewed here, instead of silently following wherever v1 moves.

There was never a v0 reference in this workflow, and there is no api-key
presence check to remove — the action is invoked directly and fails loudly
if JUNIE_API_KEY is absent, which is the intended behaviour.

For the record, since this commit will re-trigger the job on PR #12: the two
failures there today are neither the workflow nor the Junie balance. Both
died in under ten seconds at the action's GitHub permission pre-check with
GitHub's own 503 body ("No server is currently available to service your
request"), before any Junie API call was made.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK

.github/workflows/junie-review.yml

@@ -39,7 +39,9 @@ jobs:
     steps:
     - uses: actions/checkout@v4
     - name: Review the pull request
-      uses: JetBrains/junie-github-action@v1
+      # Pinned to the newest release rather than the moving v1 tag, so the version
+      # running is the version reviewed here. Bump deliberately.
+      uses: JetBrains/junie-github-action@v1.7.4
       with:
         junie_api_key: ${{ secrets.JUNIE_API_KEY }}
         # Built-in structured review prompt, as opposed to a free-form instruction.