fix(ci): disable target/ cache for Swift packaging job

[dannym-arx]

The macos-26 runner pin in #312 looked right but didn't actually change anything: the auto-republished libmdk_uniffi.a on mdk-swift@main came out byte-for-byte identical to the pre-#312 archive (same LFS SHA, same 115864704 bytes), and here's why.

What happened

The package-swift job runs Swatinem/rust-cache. Its default key is (Darwin-arm64, Cargo.lock hash, Rust version). None of those changed when we bumped from macos-latest (15) to macos-26-arm64, so the cache for package-swift from PR #309's run on macos-15 hit cleanly on PR #312's run on macos-26 and restored the entire target/ directory.

The actions log on PR #312's package-swift job tells the story:

Image: macos-26-arm64
Cache hit for: v0-rust-package-swift-Darwin-arm64-9d946206-62f91f02
Cache restored successfully
... 77 seconds later ...
xcodebuild -create-xcframework ...

A clean Rust + SQLCipher + secp256k1 compile takes about 10 minutes. 77 seconds means cargo found everything pre-built in target/, relinked the same object files, and walked out the door whistling. The C deps (libsqlite3-sys, secp256k1-sys) had been compiled against the Xcode 16.4 iPhoneSimulator 18.5 SDK in the previous macos-15 run, so they kept their sdk=18.5 Mach-O tags even though the host machine now had Xcode 26.2 available.

The fix

Set cache-targets: false on the Swatinem/rust-cache step in package-swift. That keeps registry / crate-source caching (cheap and harmless, saves the cargo fetch step) but forces target/ to rebuild from scratch every push. The C deps then always compile against whatever Xcode the current runner has, so the resulting archive matches the toolchain it claims to come from.

Tradeoff: build time goes from about 1 minute (cache hit) to about 10 minutes (clean compile). That is the correct cost for a job that publishes a shippable artifact, and it's a once-per-push job on a macos-26 runner, so the wall-clock impact is fine.

Scope

This only touches the package-swift job. Python, Ruby, and Kotlin jobs keep their cache because their published artifacts aren't sensitive to Xcode SDK tags (Python / Ruby ship a .dylib; Kotlin runs on Linux).

Verification plan

1. Merge to master.
2. The push triggers package-mdk-bindings.yml with the new YAML, which means cache-targets: false takes effect on this very run.
3. The resulting mdk-swift@main should land with a fresh LFS SHA for Binary/mdk_uniffi.xcframework/ios-arm64-simulator/libmdk_uniffi.a (NOT 5b918c5b51145f4ee6a0a16a40ed79dd8e1676acb928f4e3ad5d438864b89006).
4. Extracting the new sim slice should show all C deps tagged sdk=26.x instead of the previous 5 stragglers at sdk=18.5.

I'll spot-check the new archive once the workflow lands and update marmot-protocol/mdk-swift#1.

Relates to marmot-protocol/mdk-swift#1, follow-up to #312.

---

This PR fixes the Swift packaging GitHub Actions workflow to disable caching of Rust build targets, ensuring that C dependencies are rebuilt against the current Xcode SDK on each run rather than reusing pre-compiled objects cached from a different macOS runner version. The change prevents SDK tag mismatches that could result in binary artifacts with stale Mach-O SDK references.

What changed:

• Added cache-targets: false configuration to the Swatinem/rust-cache step in the package-swift job within .github/workflows/package-mdk-bindings.yml, with explanatory comments documenting why target directory caching must be disabled
• Updated crates/mdk-uniffi/CHANGELOG.md with a "Fixed" entry documenting this workflow behavior change
• The package-swift job now rebuilds the target/ directory on every run while retaining registry and crate-source caching
• Other language-specific packaging jobs (Python, Ruby, Kotlin) are unchanged and retain their cache configurations

[stage-review]

Ready to review this PR? Stage has broken it down into 2 individual chapters for you:

	Title
1	Disable target caching for Swift packaging
2	Document Swift packaging cache fix

_{Chapters generated by Stage for commit 69d5a32 on May 21, 2026 2:54pm UTC.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR disables Rust build target caching in the Swift packaging GitHub Actions workflow to prevent stale iOS SDK artifacts from being restored on the macOS runner, and documents this fix in the changelog.

Changes

Swift Packaging Rust Cache Target Disabling

Layer / File(s)	Summary
Workflow cache configuration and changelog .github/workflows/package-mdk-bindings.yml, crates/mdk-uniffi/CHANGELOG.md	The package-swift job disables Rust cache targets via cache-targets: false with comments explaining why target-cache reuse must be avoided on the pinned macOS runner. The changelog documents this fix to ensure C dependencies rebuild on every push.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• marmot-protocol/mdk#312: Both PRs address iOS SDK/xcode consistency in the Swift packaging workflow—fix(ci): build Swift package on macos-26-arm64 for iOS 26 SDK #312 pins the macOS runner to macos-26-arm64, while this PR disables target caching to prevent stale artifacts.
• marmot-protocol/mdk#279: Both PRs modify the Rust caching configuration in .github/workflows/package-mdk-bindings.yml, with this PR disabling target caching while the other PR focuses on cache-tool pinning.

Suggested reviewers

• mubarakcoded
• jgmontoya
• erskingardner

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately describes the main change: disabling the target/ cache for the Swift packaging GitHub Actions job via the cache-targets: false configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
No Sensitive Identifier Leakage	✅ Passed	No sensitive identifiers leak in tracing, format!, panic!, or Debug impls. All Debug implementations properly redact GroupId/mls_group_id. PR only modifies CI YAML and CHANGELOG.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/swift-rust-cache-no-target

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[erskingardner]

🤞

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/mdk-uniffi/CHANGELOG.md`:
- Line 43: The changelog entry that starts "Swift packaging now rebuilds C
dependencies..." ends with an issue link; change that trailing reference to the
corresponding PR reference (use the PR number and PR URL for mdk-swift) so the
entry follows policy of referencing PRs not issues—update the final
parenthetical reference at the end of that paragraph to point to the PR (e.g.,
marmot-protocol/mdk-swift#<PR_NUMBER>) instead of the issue link.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 19777588-b0c3-4f80-a09d-5123d6b33d36

📥 Commits

Reviewing files that changed from the base of the PR and between 47e2ff3 and 69d5a32.

📒 Files selected for processing (2)

• .github/workflows/package-mdk-bindings.yml
• crates/mdk-uniffi/CHANGELOG.md