feat(ui/approvals): Approval queue missing Account/Term/Payment/Monthly columns + shows user-id instead of email

[cristim]

Approval queue renderer at frontend/src/history.ts:848-899 shows only Date / Provider / Service / Count / Upfront / Monthly Savings / Created by (raw user_id) / Actions. Operators approving purchases need Account, Term, Payment, Monthly/Yearly Cost — the backend PurchaseHistoryRecord (internal/config/types.go:445-516) already carries AccountID/Term/Payment/MonthlyCost but the frontend HistoryPurchase (frontend/src/types.ts:174-233) doesn't expose them and the renderer doesn't read them. The "Created by" column shows a UUID instead of email.

Also covers row 1.3 — once the Payment and MonthlyCost columns are surfaced, the divergence between Approval-queue "Eff. Savings" and Opportunities table's effective-savings formula can be reconciled (or the column renamed to "Monthly Savings" to match its actual semantic).

Fix direction

(a) Extend HistoryPurchase with account_id, term, payment, monthly_cost (already in JSON).
(b) Backend: add a CreatedByUserEmail field populated by joining executions → users in internal/api/handler_history.go executionToHistoryRow (~lines 180-215). Keep created_by_user_id for the cancel-own UX gate.
(c) Render the new columns in renderApprovalQueue; resolve account name via accountNamesCache (already imported by recommendations.ts — export it to a shared module).
(d) Decide: compute Effective Savings in the queue (same formula as Opportunities), or rename the column to "Monthly Savings".

Surfaced by QA spreadsheet rows 1.1 and 1.3.

[cristim]

QA verification still failing after PR #713 merged

Re-tested row 1.1 (Approval queue columns, spreadsheet row 274). The columns were added but the data is missing:

"The Account and Payment columns are now shown, but they have no data, only a dash ('-')."

So the column headers/cells render but the underlying API/data wiring doesn't populate them. Likely:

• Backend isn't returning account_name / payment_option fields on the executions endpoint.
• OR the frontend reads the wrong field path.
• OR the column accessor falls back to - because the value is null/undefined.

Reopening this thread - please trace the data path from DB -> API -> frontend cell and ensure the Account/Payment values populate.

[cristim]

Verified as resolved via QA exploratory testing (marked Pass in the QA spreadsheet). Shipped in PR #713 (and follow-up PR #738 merged to backfill Account/Payment/MonthlyCost data). Closing.