feat: Update documentation for memory vault integration and work items, clarifying usage of Obsidian CLI and resolving Fid4 dependency conflicts

vault/01-current/current-work.md

@@ -18,7 +18,7 @@ tags:
 - Follow up on active tickets through `vault/02-work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
 - Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
 - After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
-- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by getting the remaining FTFrameworks code-owner approval on the XFlowViewMaker PR, then run the pipeline and update Fid4 while continuing `PDIAP-15838` in parallel where possible
+- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by carrying the already-published XFlowViewMaker update through the Fid4 PR and downstream consumer path
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
 - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
 - Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
@@ -35,7 +35,8 @@ tags:
 - When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
 - The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
 - The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
-- The `PDIAP-15765` compatibility fix is now merged and released in XFlow `2.8.48`; the remaining near-term work is getting the last FTFrameworks code-owner approval on the XFlowViewMaker PR, then running the pipeline and updating Fid4
+- The `PDIAP-15765` compatibility fix is now merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up has also been approved, published, and unblocked in Fid4 through a podspec-repo change, and the current downstream step is the open Fid4 PR/update path
+- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
 - Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
 - The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
 
@@ -50,6 +51,7 @@ tags:
 - Preserving accurate context when summarizing work from another machine
 - Validating dismissal sequencing changes across SwiftUI flows
 - Keeping REST deprecation scope explicit while GraphQL fallback still exists
+- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
 - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
 - Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording
 - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope