fix: separate payment timing phases

[Jo-anny]

Separate payment settlement timing from provider search timing

Summary

This PR separates the paid search flow into distinct timing phases so the frontend reflects actual latency sources instead of measuring a single optimistic total.

The previous implementation advanced the flow based on promise creation rather than the real lifecycle of each payment/search stage. The result hid where time was being spent between challenge, signing, settlement, provider work, and rendering.

Changes

• Added explicit timing phases in the search session:
  • challenge
  • signing
  • settlement
  • provider
  • rendering
• Updated the search hook to record the real elapsed time for each phase.
• Corrected the active/completed state logic in the payment flow visualizer so it reflects the actual lifecycle events.
• Added a focused regression test covering the timing state model.
• Documented the timing breakdown in the README.

Acceptance criteria

• Challenge, signing, settlement, provider, and rendering timings are captured
• The active and completed phases reflect actual events rather than promise creation
• Automated coverage and documentation are updated where the behavior changes

Notes

This keeps the search flow aligned with the x402 payment semantics while making frontend latency reporting accurate and explainable.

closes #143

[vercel]

@Jo-anny is attempting to deploy a commit to the Emmanuel's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Jo-anny Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits