Fix: move AsyncWorker start to app lifespan to resolve FastAPI router…

[ericdes]

… bug

Summary

Moves the AsyncWorker lifecycle management to the FastAPI application lifespan and ensures the background worker maintains its own persistent database client.

Type of Change

• Bug fix
• New feature
• Performance improvement
• Documentation/Tests

Objective

The previous implementation attempted to start the background worker within an APIRouter lifespan. In certain FastAPI configurations, this can lead to race conditions where the worker fails to start. Furthermore, using request-scoped database clients within background tasks often resulted in "connection closed" errors, as the request context frequently concludes before the worker queue finishes processing.

This change:

Migrates worker start/stop to the global FastAPI lifespan in main.py.
Provides the AsyncWorker with its own persistent ZepGraphiti client.
Hardens the worker loop with error handling to ensure continuous operation even if a single job fails.

Testing

• Unit tests added/updated
• Integration tests added/updated
• All existing tests pass

Breaking Changes

• This PR contains breaking changes

If this is a breaking change, describe:

• What functionality is affected
• Migration path for existing users

Checklist

• Code follows project style guidelines (make lint passes)
• Self-review completed
• Documentation updated where necessary
• No secrets or sensitive information committed

Related Issues

Closes #[issue number]

[danielchalef]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[ericdes]

I have read the CLA Document and I hereby sign the CLA