fix: resolve #807, #808, #809, #810 — ID retry, dashboard pagination, E2E webhook/SSE, report index

[topsonDev]

Summary

This PR resolves four open issues in a single batch.

---

StellarEdu#807 — generateStudentId collision retry

Problem: Under concurrency, two registrations could pass the Student.exists() check simultaneously, then both call Student.create(). The second write hit the unique index and surfaced as an opaque 409.

Fix (backend/src/controllers/studentController.js):

• Track autoGenerated flag when no studentId is supplied in the request body.
• Hoist assignedFee / assignedDeadline to function scope so the catch block can access them during a retry.
• On a MongoDB 11000 error with an auto-generated ID, call generateStudentId() again (up to MAX_ID_RETRIES attempts) and retry Student.create() with the new candidate.
• Only propagate DUPLICATE_STUDENT (409) when the caller supplied the ID explicitly, or after all retry attempts are exhausted.

---

StellarEdu#808 — Frontend dashboard pagination

Finding: frontend/src/pages/dashboard.jsx already implements full server-side pagination, debounced search, status/class filters, and skeleton loading. Stat counts are sourced from the /payments/summary aggregate endpoint. The acceptance criteria are satisfied by the existing implementation; no code changes were required.

---

StellarEdu#809 — E2E test: webhook + SSE side effects

Problem: The pipeline E2E test suite had no assertions covering the webhook and SSE side effects that fire after a successful payment.

Fix (tests/e2e/paymentPipeline.e2e.test.js):

• Scenario 7 — webhook: configures a webhookUrl on the school, spies on webhookService.notifyPaymentConfirmed, calls verifyPayment, and asserts the webhook was fired with the correct URL, payment payload (txHash, status: 'SUCCESS'), and HMAC secret.
• Scenario 8 — SSE: spies on sseService.emit, triggers syncAllPayments with a matched transaction, and asserts the 'payment' event was emitted on the correct school channel with the expected txHash.
• Both scenarios run against mongodb-memory-server with no real network calls; CI-safe.

---

StellarEdu#810 — Compound index alignment for report queries

Problem: reportService.aggregateByDate matched { schoolId, status: 'SUCCESS', studentDeleted: { $ne: true } } but omitted deletedAt: null. The partial compound index on payments has partialFilterExpression: { studentDeleted: { $ne: true }, deletedAt: null }. Without both conditions the planner could not use the index and fell back to a COLLSCAN.

Fix (backend/src/services/reportService.js):

• Added deletedAt: null to the $match stage in aggregateByDate so the query fully satisfies the partial filter expression.
• Added hint({ schoolId: 1, status: 1, confirmedAt: -1 }) to the aggregate call to pin the planner to the partial compound index and prevent in-memory sorts on confirmedAt.
• getDashboardMetrics already includes deletedAt: null in all its $match stages; no further changes needed.

---

Files changed

File	Issue
backend/src/controllers/studentController.js	StellarEdu#807
backend/src/services/reportService.js	StellarEdu#810
tests/e2e/paymentPipeline.e2e.test.js	StellarEdu#809

Testing

• Existing unit and integration tests continue to pass.
• New E2E scenarios (7 & 8) run without real network calls using mongodb-memory-server and the existing fakeHorizon fixture.

Closes StellarEdu#807
Closes StellarEdu#808
Closes StellarEdu#809
Closes StellarEdu#810