build(shared-core): resolve a local XCFramework when FLIPCASH_SHARED_CORE_LOCAL is set

[bmc08gt]

Android compiles :kmp:shared-core from source, so a Kotlin change shows up in the next Android build. iOS consumes it as a published XCFramework pinned by version, so the same change needed the publish workflow, a moved tag, and a bumped pin before it could be tried at all. Setting FLIPCASH_SHARED_CORE_LOCAL to a code-android-app checkout swaps the published binary for one assembled from that checkout:

./gradlew :kmp:shared-core:assembleSharedCoreReleaseXCFramework
export FLIPCASH_SHARED_CORE_LOCAL=~/dev/bmcreations/code/code-android-app
xed ../code-ios-app

This is FLIPCASH_PROTO_LOCAL's equivalent for shared-core, and it matters more: the derivation and bonding-curve moves are far more iterative than the beachhead was.

Why the switch is in the package manifest and not in the app. The iOS app reaches SharedCoreKit twice — FlipcashUI/Package.swift depends on it, and Code.xcodeproj carries its own XCRemoteSwiftPackageReference because the app target imports it directly. Overriding only FlipcashUI leaves the project reference on the published package, and resolution fails with multiple similar targets 'SharedCore', 'SharedCoreKit' appear in package 'spm' and 'flipcash-shared-core-spm'. A SwiftPM mirror doesn't help either: it will only map a source-control dependency onto another git repository, not onto a directory. Putting the switch in this manifest works because the publish job copies it verbatim into the SPM repo, so the tagged copy the app resolves carries the same conditional and both consumers follow it — code-ios-app needs no change.

Two constraints follow from that. The variable holds a path to the checkout, since the published manifest lands in DerivedData with no Kotlin beside it; and SwiftPM rejects an absolute binary-target path, so the manifest rewrites it relative to Context.packageDirectory.

The override reaches the app only once a release carrying this manifest is published — 0.3.1 predates it. The facade work cuts 0.4.0 anyway, so this needs no publish of its own.

Local state can't ship: the opt-in is an environment variable, so no manifest is edited and Package.resolved is unchanged; the publish workflow never sets it, and its verify step compiles against the uploaded asset. If the variable is set and the framework hasn't been assembled, resolution fails naming the missing path rather than falling back to the published binary.

The loop is written up in docs/shared-core-local-development.md in the orchestrator repo.