Module account_backend 

Persistent account-link stores. Schema mirrors better-auth’s account table so apps migrating between the two see the same field names + meanings.

• SqliteAccountBackend — single-file durability for self-hosted single-replica deploys. Lives alongside sessions/oauth-state in PYLON_SESSION_DB.
• PostgresAccountBackend — for DATABASE_URL=postgres://... deploys. Stores account rows in the same Postgres cluster as the user’s data so a join across _pylon_accounts and the manifest’s User entity works without cross-database queries.

Both implement pylon_auth::AccountBackend. Why a dedicated table instead of folding the link into the manifest’s User entity:

1. Multi-provider: a single user can link Google + GitHub + custom IdPs + a password (provider_id="credential"). The User row needs one identity-of-record (email), not N nullable provider columns.
2. Refresh token + password storage: provider secrets and password hashes shouldn’t be in the user-visible entity surface — hiding them in a framework table keeps them out of /api/entities/User responses by default.
3. Schema agility: the framework owns the account schema, so adding a new provider column doesn’t require a manifest migration in every consumer app.

Structs

PostgresAccountBackend

SqliteAccountBackend