- M3HiuWorkflowService: data_fetch now supports fetch_by_request_id=1, sending request_id (not consent_id) per bridge Method 1 -- targets the current/self consent request's own session, distinct from Method 2 (consent_id, which can resolve to a stale session sharing the same artifact).
- Patient::abdm_content_fetch_only(): tries Method 2 (consent_id) -> Method 1 (request_id, self data) -> Method 3 (abha_address, historical fallback) in order, stopping as soon as real documents are found.
- Fixed a real pre-existing bug this surfaced: getLatestAbdmSyncSnapshot() used the same flawed 'status=SUCCESS implies COMPLETED' check (without requiring workflow_state=DATA_RECEIVED) already fixed elsewhere in computeConsentSessionDetail(). This let broad/historical data_fetch rows (status=success, but decrypted_data=[]) hijack priority-500 'best' selection and silently drift the resolved 'latest granted consent' to an unrelated historical consent_id after Method 3 fallback ran. Now requires workflow_state=DATA_RECEIVED, matching the earlier fix.
Per bridge gateway team guidance, GET /v1/hiu/data/fetch?abha_address=... returns ALL historical decrypted records across every past consent for a patient, unlike the consent/request-scoped Methods 1/2 previously used exclusively. Added M3HiuWorkflowService support for a fetch_by_abha_address flag on the data_fetch operation, and wired abdm_content_fetch_only() to automatically fall back to this broader lookup when the consent-scoped fetch finds nothing new -- this surfaced 14 previously-invisible historical documents (consultation reports, pathology/cytology) for the test patient that were never being fetched before.
