fix(api): complete unimplemented DB operations in plan API handlers

[Pvsaint]

Summary

Closes #1037

This PR completes all five unimplemented database operations in backend/src/api.rs that were marked with // Contributors: placeholder comments.

---

What was already implemented

After a thorough audit, three of the five handlers were fully implemented behind their placeholder comments and only needed the comments removed:

Handler	Status before this PR
create_plan	✅ Full atomic SQL transaction — INSERT into plans then INSERT per beneficiary, COMMIT, webhook enqueue
update_plan	✅ BPS validation (sum must equal 10 000), transactional DELETE + re-INSERT of beneficiaries, grace period / yield field updates
get_plans	✅ Dynamic owner/beneficiary filtering, on-the-fly yield accumulation via compute_projected_accrued_yield, Redis cache with timing headers

---

What was genuinely missing and is now fixed

1. ping_plan — atomic ping log insertion (line 1180)

Before: The handler updated plans.last_ping and plans.accrued_yield with a bare execute call, then returned. No audit record was ever written to ping_logs.

After:

• The UPDATE plans and the new INSERT INTO ping_logs are wrapped in a single BEGIN / COMMIT transaction, so both succeed or both roll back atomically.
• The ping_logs row captures pinged_at (server NOW()) and accrued_yield_snapshot (the yield accumulated up to this ping), satisfying the audit-log requirement.
• inactivity_deadline_at is a generated column (to_timestamp(last_ping + grace_period_seconds)) so it is kept in sync by Postgres automatically whenever last_ping is updated — no extra write needed.

2. trigger_payout — plan.settled webhook emission (line 1281)

Before: After committing the payout transaction and invalidating the cache the handler returned immediately. No webhook was dispatched.

After:

• After cache invalidation, WebhookDispatcherService::enqueue_event is called with event type "plan.settled" and a JSON payload containing plan_id, owner, total_payout, status, and payout_count.
• The call is non-blocking and non-fatal — a failure to enqueue is logged as a warn! and does not affect the HTTP response, keeping the payout itself fully atomic.

---

Testing

• cargo build --no-default-features — clean build, zero errors.
• cargo test --no-default-features --lib — 53/53 unit tests pass.
• No new test infrastructure was required; the changes slot into the existing transaction patterns already established throughout the file.

[ONEONUORA]

Great job @Pvsaint