fix(fde): document and propose solution for patient context loss after registration

[Spoorthy-Vaddepally]

Summary

This PR documents an issue observed in the Fast Data Entry (FDE) workflow where the patient context is temporarily lost immediately after patient registration, leading to workflow reinitialization and, in some cases, interrupted form submission.
The purpose of this PR is exploratory and consultative:

• to clearly describe the problem,
• share concrete observations gathered from runtime diagnostics,
• propose a possible direction for a fix,
• and request maintainer feedback before implementing behavioral changes.
• No functional behavior is altered in this PR.

Problem Description
During the Fast Data Entry workflow with patient registration:
A new patient is successfully created.
The application navigates back to the form route with patientUuid present in the URL.

Before the workflow state stabilizes:

• workflowState remains null
• activePatientUuid is not yet available in state.forms[activeFormUuid]

This triggers workflow initialization again, causing:
temporary loss of patient context
workflow reset during an active session

Shortly after, the patient context recovers, but the workflow has already passed through an inconsistent intermediate state.
This behavior is reproducible and occurs specifically during the post-registration transition.

Observations

• From detailed runtime logging:
• patientUuid becomes available via the URL immediately after registration.
• INITIALIZE_WORKFLOW_STATE may execute while patient context has not yet been reconciled into workflow state.
• This results in workflow initialization occurring earlier than intended.
• Patient context is eventually restored, confirming the issue is timing-related, not data loss.

Proposed Direction (for Discussion)
Based on these observations, a potential solution could involve:

• Preventing workflow initialization while:
• patientUuid is present in the URL
• but the workflow state has not yet associated it with activePatientUuid
• Ensuring workflow initialization occurs once per form session, after patient context is fully established

Alternatively, temporarily treating patientUuid from the URL as authoritative during initialization
These ideas are presented for discussion only and are not enforced in this PR.

What This PR Does

• Adds structured diagnostic logging to clearly surface the issue
• Documents the workflow behavior and timing sequence
• Provides evidence to support the proposed solution direction

What This PR Does Not Do

• Does not modify reducer logic
• Does not change workflow behavior
• Does not introduce new UI changes
• Does not finalize a fix

Testing Performed

• Manual end-to-end testing was conducted by:
• Navigating through Fast Data Entry
• Registering a new patient
• Observing workflow initialization and state transitions
• Verifying behavior during form interaction and submission
• Reproducing the issue consistently using runtime diagnostics
• No automated tests were modified.

Request for Feedback
Before proceeding with a behavioral fix, I would appreciate guidance on:
Whether delaying workflow initialization aligns with intended FDE design
Whether patientUuid from the URL should be used as a temporary source of truth
Any preferred patterns already used in the codebase for handling similar timing issues

I’m happy to follow up with a focused fix once the direction is confirmed.

Thank you for reviewing, and I appreciate any feedback or suggestions.