Policy Edit on a Product

#### Description:

Revisit how we want to edit a Policy on a Product.

From [#250](https://github.com/bcgov/reserve-rec-admin/issues/250):

> The issue we're going to encounter eventually is if the user edits policies, but that has bigger ramifications because that would mean we need to do a couple things:
>1) update the policy on the product data item to reference the correct policy (easy, chill)
>2) update all the productDates (and I think inventoryPool in some cases?) items that reference the policy change (wholesale deletion/editing, less chill).

>But currently we just have the four policies specific to DUP anyway, so there's not going to be any policy editing at this moment. I think we revisit this when we know what making more policies looks like, if we even want to have a user edit a policy as opposed to deleting the product and re-creating it, or if Backcountry policies even show for DUP products, and so on.

#### Acceptance Criteria:
[Note: Use 'Given/When/Then' format if it makes sense to. Otherwise, a simple checklist that can be tested.]

Given I'm a user
When I edit a policy on a product
Then that product, and items related to that product (productDate, inventoryPool) are updated

#### Development Checklist:

- [ ] Updates product, productDate, inventoryPool items
- [ ] ...
- [ ] ...

#### Dependencies

- Blocked by
- Blocking

**Relevant documentation as reference**

**Definition of Ready**

- [ ] Acceptance criteria are included
- [ ] Wireframes are included (if applicable)
- [ ] Design / Solution is accepted by Product Owner (if applicable)
- [ ] Dependencies are identified (technical, business, regulatory/policy)
- [ ] Story has been estimated (under 13 pts)

**Definition of Done**
- In progress:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] UI meets accessibility requirements
- [ ] Unit tests are written
- [ ] Work is traceable in GitHub
- [ ] PR linked to ticket number
- [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
- Code review:
- [ ] Code is peer reviewed and has passed CI/CD tests
- QA:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] Code is potentially shippable to the production environment
- [ ] Functional features have been tested and passed by QA
- [ ] UI components tested by designer
- [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
- PO Review:
- [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- [ ] Reviewed and approved by Product Owner

**Security Validation Checklist**
- Security-focused Peer Review:
- [ ] Reviewer explicitly considers abuse cases, privilege boundaries, and insecure patterns.
- Static Analysis Passed:
- [ ] Security linting tools (e.g., Bandit, ESLint plugins, SonarQube) executed and cleared
- Rate Limiting & Bot Defenses Verified:
- [ ] Anti-automation strategies (e.g., throttling, CAPTCHA/Turnstile, scoring) tested and confirmed.
- Threat Model Completed:
- [ ] Developers have identified potential attack vectors (e.g., spoofing, privilege escalation, data leakage), documented mitigations, and validated that defenses align with system goals and fairness principles.

#### Notes:
-
-

The issue names no files, tests, or entry points; first clarify whether policy editing is supported and define how product, productDate, and inventoryPool references should change. Done means an agreed implementation scope and tests demonstrating the required updates.

Written by the indexing model from the issue text.