bug(api/approvals): approval toast names hardcoded contact email, not Admin notification_email #735

Symptom (QA row 250, Purchases page > Opportunities flow step 5.6)

When an admin user clicks "Purchase 1 selected" -> "Send all for approval" for an Azure commitment, the success toast says:

Approval request sent to jcorbett@archera.ai

even though cristi@leanercloud.com is set as Notification email under Admin > General Settings.

Subsequently, in Purchase History on the Purchases page, the row shows:

awaiting approval from cristi@leanercloud.com

So two different "approver" identities are surfaced for the same execution:

1. The toast names the email of the user who is hard-coded somewhere (likely the original Archera contact for the org), instead of the Admin-set notification email.
2. The Purchase History row correctly shows the Admin-set notification email.

This is confusing and a real bug: it is unclear who actually receives the approval email. If the toast is correct, the Admin Settings field is ignored. If the Purchase History row is correct, the toast displays stale/wrong data.

Reproduction

1. Set Notification email = cristi@leanercloud.com under Admin > General Settings.
2. From Opportunities, select an Azure recommendation -> "Purchase 1 selected" -> "Send all for approval".
3. Observe the toast: it names a different email than cristi@leanercloud.com.
4. Open Purchase History -> the row shows awaiting approval from cristi@leanercloud.com.

Fix direction

Trace the toast message's data source. The likely culprits:

• Frontend hardcoding the Archera contact email when building the toast string (look for jcorbett or a default approver constant in frontend/src/).
• API returning a different approver field than what Purchase History reads. The Purchase History row clearly uses the right notification email, so the toast just needs the same data source.

Whichever is wrong, fix it so both UIs show the Admin-set notification email (and the email actually goes there).

Tests required

• Acceptance test: change Notification email in Admin Settings, kick off an Azure purchase approval from Opportunities, assert the toast names the same email shown in Purchase History.
• Backend regression: ensure the approval-email-send path uses config.notification_email, not a hardcoded default.

Source of finding

QA verification spreadsheet row 250 (step 5.6 of Opportunities > Purchase).