feat(notifications): expose delivery and ACK evidence

[chuanxu742-glitch]

Closes #84

Product outcome

• Adds a dedicated delivery-evidence section to the notification center.
• Separates technical channel submission from downstream business ACK semantics.
• Shows rule, transport state, ACK state, record id, time, and an allow-listed safe error summary without rendering raw response or ACK payloads.
• Keeps rule management usable when log loading fails, and preserves already-loaded rows when refresh or load-more requests fail.

Operability and data integrity

• Adds pagination for both rules and delivery attempts, exact rule lookup for log rows outside loaded rule pages, and stable-id deduplication for offset pagination overlap.
• Refreshes both rule and log caches after cascaded rule deletion.
• Warns before rule deletion that all associated delivery evidence is permanently removed.
• Treats provisional not_required ACK values according to transport state while allowing a real downstream ACK to override a transport-side timeout/failure inference.

Verification

• node --experimental-strip-types --test scripts/notification-delivery-status.test.mjs scripts/check-notification-evidence-regressions.mjs — 14/14 passed
• node node_modules/typescript/bin/tsc --noEmit — passed
• targeted ESLint — 0 errors
• node node_modules/next/dist/bin/next build — passed, 42/42 pages generated
• git diff --check — passed
• independent verifier review — no findings after two review/fix cycles

[coderabbitai]

Warning

Review limit reached

Next included review available in 25 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: faa5ea95-cbcc-45b4-96a5-474a93248c35

📥 Commits

Reviewing files that changed from the base of the PR and between b9ec317 and 47c3cdc.

📒 Files selected for processing (6)

• frontend/app/(app)/notifications/page.tsx
• frontend/lib/api/endpoints.ts
• frontend/lib/api/hooks.ts
• frontend/lib/notifications/delivery-status.ts
• frontend/scripts/check-notification-evidence-regressions.mjs
• frontend/scripts/notification-delivery-status.test.mjs

Warning

Your free Security trial is over. An organization admin can activate billing to continue.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 47c3cdc015

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Add a stable order before paging notification rules

When more than 50 rules exist, this fetches successive offset pages from list_rules, but the backend query in backend/api/v1/notifications.py:40-42 applies OFFSET/LIMIT without any ORDER BY. SQL does not guarantee a consistent row order between requests, so loading the next page can duplicate already displayed rules and permanently omit others; the client-side deduplication only hides duplicates and cannot recover skipped rules. Add a deterministic backend ordering (ideally with a unique tie-breaker) before relying on this infinite query.

Useful? React with 👍 / 👎.