Post reason why request is Closed - Comment and Notification

* As an IAO analyst or ministry coordinator
* I want to be able to see the reason why a request is Closed
* so that I know why the request was closed

**Assumptions & Scope**
What are the assumptions for this story?

IAO and ministries want to see the reason why a request was Closed.

Assigned users will see the reason the request was Closed in their notifications.

IAO can already select the reason why a request is Closed in the app, but we do currently not post the reason anywhere on the request or include the reason in the notifiication.

What is in and not in scope?
Add the reason why a request is posted in the comment and the notification

**Not in Scope**
Closing and selecting a reason a request is Closed #469
Reason a request was Closed on Advanced Search and Queue #4920

**Acceptance Criteria**

**Scenario 1: Reason for Closing Request posted in Request History comment**
* GIVEN the IAO analyst has Closed a request
* AND the reason selected is one of the following options: Abandoned, Access Denied, Application Fee - Abandoned, Full Disclosure, No Resp. Records Exist/Located, Outside Scope of Act, Partial Disclosure, Records in Another Min/Org, Refuse to Confirm or Deny, Routinely Releasable, Section 43, Transferred, Withdrawn
* WHEN the comment is posted in the Request History
* THEN the comment will include the reason and say, "(USER) changed the state of the request to Closed. The reason for the closure is (REASON, e.g., Access Denied, Transferred, etc.)

**Scenario 2: Reason for Closing Request included in notification**
* GIVEN a FOI Request is in any state
* WHEN the state of the request changes to Closed
* THEN all users assigned to the request, EXCEPT for the user that made the change, will receive a notification that includes: FOI Request number, and a message saying "Moved to Closed State as REASON (e.g. Abandoned)" through a pull notification that occurs every 15 minutes.
*
**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?

The issue names no files, tests, or entry points. Start by tracing request state changes, Request History comments, and pull notification generation; compare the existing closure reason handling with both acceptance scenarios. Done means the closure reason appears in the history comment and in notifications to other assigned users, with tests covering the listed reasons.

Written by the indexing model from the issue text.