feat(release): add generation workflow

Add a guarded mobile release skill that synchronizes public versions, writes on-brand notes, verifies signed iOS and Android artifacts, and tags the verified release commit.

.codex/skills/generate-release/references/artifact-verification.md

@@ -0,0 +1,39 @@
+# Release artifact verification
+
+Use the strongest locally available platform tools and record the commands and
+results. Never print provisioning profiles, keys, tokens, or environment values.
+
+## Android AAB
+
+Require a production `.aab`. Inspect its manifest with `bundletool dump manifest`
+or Android SDK `apkanalyzer`, and verify:
+
+- package `com.sauci.app`;
+- `versionName` equals the release version;
+- `versionCode` equals the recorded Android build number.
+
+Verify the archive signature with `jarsigner -verify -verbose -certs`. Compare the
+signing certificate SHA-1 to the production fingerprint documented in
+`docs/releasing.md`; do not copy credentials into commands or reports. Calculate
+the artifact SHA-256 with `shasum -a 256`.
+
+## iOS IPA
+
+Extract the `.ipa` into a new temporary directory created with `mktemp -d`. Read
+the application `Info.plist` with `/usr/libexec/PlistBuddy` or `plutil` and verify:
+
+- `CFBundleIdentifier` is `com.sauci.app`;
+- `CFBundleShortVersionString` equals the release version;
+- `CFBundleVersion` equals the recorded iOS build number.
+
+Use `codesign -dvvv` and `codesign --verify --deep --strict` on the extracted app
+to inspect and verify signing without exposing the embedded profile. Calculate the
+original `.ipa` SHA-256 with `shasum -a 256`. Remove only the explicit temporary
+extraction directory after inspection.
+
+## Source correspondence
+
+For both platforms, retain the build command, artifact path, build completion
+time, and digest in the final report. Compare the post-build tracked diff with the
+documented allowed version files. A binary with the right version but unexpected
+source regeneration, wrong signing, or an unverifiable manifest is not accepted.

.codex/skills/generate-release/references/release-notes-voice.md

@@ -0,0 +1,51 @@
+# Sauci release-note voice
+
+Sauci sounds warm, confident, inviting, and quietly playful. It is a premium
+couples app about private connection and shared curiosity: supportive without
+being clinical, polished without sounding corporate, and intimate without being
+graphic or presumptuous.
+
+## Shape
+
+Use a short opening sentence followed by three to six compact bullets. Lead with
+the change that most improves a couple's experience. Combine related work into
+one benefit rather than mirroring the commit list. Include a brief closing line
+only when it adds warmth or useful context.
+
+In `docs/release-notes.md`, use:
+
+```markdown
+## v1.2.3 — 29 August 2026
+_iOS build 44 · Android build 48_
+
+A little more ease, clarity, and connection in every check-in.
+
+- **Closer conversations** — Find the prompts that feel right for both of you.
+- **Smoother moments** — Chats and matches now feel quicker and more reliable.
+- **More control** — Clearer choices help keep your shared space comfortable.
+```
+
+Adapt the words to the evidence; do not reuse this copy when those claims are not
+present in the release. If only one platform was requested, record only its build.
+
+## Language
+
+- Address the couple's experience with `you`, `your partner`, `together`, or
+  `your shared space` where natural.
+- Prefer concrete benefits: `pick up where you left off`, `find the right prompt`,
+  `keep conversations flowing`, `stay in control`.
+- Use restrained warmth. One gentle phrase is enough; avoid forced innuendo,
+  breathless hype, exclamation marks, emoji, and claims that Sauci will improve or
+  fix a relationship.
+- Prefer `new`, `smoother`, `clearer`, `more private`, and `more reliable` to
+  `revolutionary`, `game-changing`, `massive`, or `best ever`.
+- Explain a fix as the experience restored, not the defect mechanics. Name a
+  security or privacy change plainly when users need to understand it.
+
+## Evidence boundary
+
+Release notes describe shipped behavior only. Do not claim a feature from a plan,
+flagged-off path, migration, test, or commit title without confirming the runtime
+path in the diff and release configuration. Do not expose internal service names,
+database details, moderation logic, security-sensitive implementation, or content
+that the product intentionally keeps private between partners.