[Change Requests] -Wrap CR review-and-apply flow in transactions

Description

Context

In reviewChangeRequest, the change request is marked accepted/dateReviewed in one Prisma call, then a separate method (reviewStageGateChangeRequest, reviewActivationChangeRequest, or reviewBudgetChangeRequest) actually applies the change. If that second step throws reviewStageGateChangeRequest's "Date completed cannot be before the work package start date" check the CR is left marked as accepted/reviewed even though nothing was actually applied, and the if (foundCR.accepted) throw guard means it can never be retried or reviewed again. applyLeadershipChangeRequest already does this correctly with prisma.$transaction and can be used as the reference pattern.

Task

Wrap reviewChangeRequest's update and its dispatch to reviewStageGateChangeRequest / reviewActivationChangeRequest / reviewBudgetChangeRequest / reviewStandardChangeRequest in a single prisma.$transaction. Each of those four methods' internal multi-step writes (change.createMany followed by a separate entity update) also needs to happen inside that same transaction.

Acceptance Criteria

If any step in the apply flow throws, no partial state is persisted the CR is left exactly as it was before review was attempted (still unreviewed, still reviewable).
A CR can never end up accepted: true / dateReviewed set without its corresponding changes having actually applied.
Existing successful review flows (stage gate, activation, budget, standard) behave identically to before.

Proposed Solution

...

Mocks

No response

Start at reviewChangeRequest and trace its dispatch to reviewStageGateChangeRequest, reviewActivationChangeRequest, reviewBudgetChangeRequest, and reviewStandardChangeRequest. Read applyLeadershipChangeRequest first for the existing prisma.$transaction pattern, then inspect each method's multi-step writes. Done means failed applies leave the CR unreviewed and successful stage gate, activation, budget, and standard reviews behave as before.