fix: atomic restore write and pid-qualified temp file

[fonkamloic]

Closes out the checkpoint-lineage items tabled (Medium/Low) from the PR #19 reviews:

• Atomic restore (Medium): restoreAndroidYaml now uses the same temp-file+rename pattern as the stamp write — a failed restore previously wrote in place and could truncate the config, a worse outcome than the stamped state.
• pid-qualified temp file (Low): parallel fcp codepush release runs in one worktree (e.g. a CI matrix building apk and appbundle) no longer collide on the temp filename.

Also syncs .github/workflows/claude-review.yml with main's severity-classified sticky-comment version so this lineage's PRs are reviewed under the same policy.

[claude]

Review: fix — atomic restore write and pid-qualified temp file

No Critical issues. The refactor is correct and both tabled items from PR #19 are properly addressed.

What the PR does

• Extracts a private _atomicWrite(path, content) helper that consolidates the temp-file + rename logic for both writeReleaseVersionToAndroidYaml and restoreAndroidYaml.
• Qualifies the temp filename with pid ($path.$pid.tmp) to prevent collisions in parallel CI builds targeting the same worktree.
• Applies the same atomic-write guarantee to restoreAndroidYaml, which previously used a bare writeAsStringSync and could truncate the config on a partial write.
• Syncs .github/workflows/claude-review.yml with the severity-classified sticky-comment version from main.

---

Findings

Medium — No tests added for the new atomic restore behaviour.
restoreAndroidYaml previously had no atomic guarantee; this PR fixes that. The new invariant — rename failure → exception + temp file cleaned up, target file untouched — is not exercised by any test in this PR. A unit test that stubs File.renameSync to throw would verify the invariant and guard against regression. (The write-side atomic path from PR #19 presumably already has coverage; the restore side is the gap.)

Low — _atomicWrite cleans up the temp file only on FileSystemException (see inline note on android_baseline_yaml.dart line 61).
In practice, Dart's File API surfaces FileSystemException for all OS errors, so the current catch + rethrow is functionally correct. A try/finally with a committed flag makes the cleanup unconditional and immune to any unexpected exception escaping the block.

---

Workflow YAML

use_sticky_comment: true is correct and matches the main-branch version. The allowedTools list already covers Bash(gh pr view:*), so the new gh pr view <n> --comments step in the updated prompt is permitted without further changes. No issues.

[fonkamloic]

Triage: no Critical findings. Tabling the Medium (unit test for the atomic-restore invariant — stub a failing renameSync, assert target untouched + temp cleaned) as a tracked follow-up. Merging per the severity policy.