Awaiting Application Fee - On Hold Function

* As an IAO user
* I want requests I move to 'Awaiting App Fee' to act like an on-hold state
* so that the new due date will be recalculated appropriately
* and the request does not have remaining days

**Assumptions & Scope**
This is an enhancement to the original Awaiting App Fee state - it was missed in the original AC that this state needed to act like a true on-hold. When a request moves to the awaiting app fee state, the remaining days should become n/a and the date should be recalculated if it moves off hold to a new state (other than closed).

Essentially this state should match the exact same business day calculation logic we use for fee estimate holds.

In addition - Intake flagged that sometimes they move requests to Open by accident - when they do this, they cannot move a request to Awaiting App Fee - and they have no way to progress backwards. This story will also add this state as a selectable option from the 'Open' state.

What is IN scope?
Updates to how Awaiting App Fee functions, including states it can be selected from

What is NOT in scope?
NO changes to existing automated notifications and comments when this state is selected.

**Acceptance Criteria**

**Scenario 1: Awaiting App Fee selectable from Open**
* GIVEN an IAO user is on a Open, General request
* WHEN they activate the state dropdown
* THEN they will see the following options - Call For Records, App Fee Owing, Peer Review, and Closed

**Scenario 2: Awaiting App Fee State**
* GIVEN an IAO user is on a request in the Open state OR Intake in progress
* AND they have the state drop down activated
* WHEN they select Awaiting App Fee
* THEN a modal will pop out with the message: 'Are you sure you want to change the request (Request ID) to App Fee Owing? The request will be placed on hold.
* AND the options will be to continue or cancel

**Scenario 3: Awaiting App Fee State**
* GIVEN an IAO user is on the awaiting App Fee Modal
* WHEN they select Continue
* THEN the modal will close and the state will be updated
* AND the the remaining days will switch to N/A
* AND The request processing days will be put on hold

**Scenario 4: Awaiting App Fee - Changing State**
* GIVEN an IAO user is on a request in the 'Awaiting App Fee' state
* WHEN they select the state drop down
* THEN the Options will be the prior state they moved from and the closed state

**Scenario 5: Awaiting App Fee - Changing State**
* GIVEN an IAO user is on a request in the 'Awaiting App Fee' state
* AND they select the state drop down
* WHEN they change the state to another state other than closed
* THEN a modal will pop out with the message: 'Are you sure you want to change the request (Request ID) to (state)? The request will be taken off hold and new due date calculated.
* AND the options will be to continue or cancel

**Scenario 6: Completing State Change**
* GIVEN an IAO user is on the state change modal after the request was on Awaiting App Fee
* WHEN they select Continue
* THEN the modal will close and the state will be updated
* AND the the remaining days will be recalculated using the existing fee hold forumla of all days not counting against the request, including the day it went on hold and the day it comes off hold
* AND The request processing days will resume

**Scenario 7: App Fee Owing - State Change Options - when you come from Open**
* GIVEN an IAO user is on a request with the state App Fee Owing
* AND the previous state was Open
* WHEN they activate the state drop down menu
* THEN they will see the following options: Open, Peer Review, Call for Records, Redirect, Closed

**Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)**

**Validation Rules? (If yes, list here)**

**Design**
@xxx - please link the Design here

**Definition of Ready**

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

**Definition of Done**

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

Start at the request state dropdown and modal flows described in the acceptance criteria, then trace the existing fee-estimate hold business-day calculation. Verify the Open and Intake in progress transitions, the Awaiting App Fee options, and the off-hold recalculation behavior. Done means all seven scenarios pass without changing existing notifications or comments.

Written by the indexing model from the issue text.