Product: Design Withdrawal and Transfer Funds Processes

### Overview
We need to design an end to end design for the withdrawl and transfer of funds proces so that there is a workflow for each scenario

#### Details
scenarios
1. (DRO withdraws, user submits and tags withdraw) User has withdrawn a TDM plan, submitted a new TDM Plan, providing the withdrawn TDM Plan ID.
1. The widthrawn plan had a paid invoice
1. The widthrawn plan does not have a paid invoice
1. (DRO withdraws, User resubmits without tagging withdraw, DRO tags) User has withdrawn a TDM plan, User has submitted a new TDM Plan, but has not provided the withdrawn ID during the submission and then they call or email the DRO who ends up having to do it after. The DRO has to get the ID of the withdrawn project from the submitter before they can proceed.
1. The widthrawn plan had a paid invoice
1. The widthrawn plan does not have a paid invoice
1. (not withdrawn, submit new TDM plan, DRO withdraws and tags) User has submitted a new TDM Plan, but has not withdrawn the original TDM plan, and the DRO needs to withdraw the current TDM Plan submission and apply the funds to the new TDM plan submission.
1. The widthrawn plan had a paid invoice
1. The widthrawn plan does not have a paid invoice

### Action Items
- [ ] Revise/update previous decision record
- [ ]

### Resources/Instructions

#### Related issues
- Documentations and Decision
- Product: Overview Documentation #2910
- Allow Withdrawl
- Product: Outdated Decision #2194
- Old Decision Record to Not Create a Withdrawal Process: https://github.com/hackforla/tdm-calculator/wiki/DR-User-application-withdrawal-through-the-TDM-site
- AN ISSUE TO UPDATE THE DECISION RECORD WILL NEED TO BE MADE
- Scenario 1
- Design: User Apply Funds Via Submit Snapshot #2874
- Dev: #3247
- Scenario 2
- Design: DRO Apply Funds Via Manage Submissions #2648
- Design: redesign DRO Apply Funds Via Manage Submissions #2876

- Dev: Add Replaced By Column to Submissions #3229
- Product: Decision #3181
- FAQ #3023

#### Staging and Release decks
- [Staging Deck](https://docs.google.com/presentation/d/1crZ3IxqA4hAu3qzD7ns93Ieuqjwh6wyEtuX_46cP-fg/)
- [Staging slide, 3250](https://docs.google.com/presentation/d/1crZ3IxqA4hAu3qzD7ns93Ieuqjwh6wyEtuX_46cP-fg/edit?slide=id.g3e420238a5f_0_0#slide=id.g3e420238a5f_0_0)
- Release Deck
- [2026-MM-DD Release deck, slide 3250]

Start by reviewing the previous withdrawal decision record linked from issue #2194, then compare the related designs in #2874, #2648, and #2876 and the implementation context in #3247 and #3229. Done means the three withdrawal and fund-transfer scenarios, including paid and unpaid invoices, are resolved in an updated decision record and corresponding workflow design.

Written by the indexing model from the issue text.