feat: Update CocoaPods dependency management guidance and index for improved clarity on versioning and release propagation

vault/03-context/workstreams/consumer-integration.md

@@ -95,6 +95,10 @@ Capture the durable release and validation path between XFlow changes and real c
 - For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
 - After that podspec-repo PR was merged, `pod install --repo-update` in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
 - `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and `ftAdapter` behavior.
+- This appears to be a risky workaround rather than a healthy long-term dependency-management pattern.
+- CocoaPods documentation recommends explicit dependency requirements in podspecs and specifically recommends the optimistic operator `~>` because it gives version control without being overly restrictive.
+- Removing version constraints entirely from published intermediate podspecs weakens compatibility guarantees, makes transitive resolution less predictable, and increases the chance that consumers pick up unvalidated downstream versions.
+- That risk is even higher in this workspace because Fid4 does not keep `Podfile.lock` in Git, so published podspec changes can alter future resolutions without a strong repository-level lockfile trail.
 
 ---