[giammin]

Summary

PersistKeysWithDapperInPostgreSQL registered its data source as an unkeyed NpgsqlDataSource singleton, which collided with a data source registered by the application (for example with AddNpgsqlDataSource): the last registration won, silently routing either the application queries or the keys to the wrong database. The instance registration also meant the container never disposed it.

• Register the data source as a keyed singleton (internal Constants.DataSourceServiceKey), created by a factory so the container owns and disposes it.
• Resolve it in PostgreSQLDataProtectionRepository with [FromKeyedServices]; the public constructor signature is unchanged.
• README and AGENTS.md updated.

Behavior changes

• An application that resolved the NpgsqlDataSource registered by this provider, without registering its own, now gets a resolution error. This relied on the bug, so it is not marked as breaking.
• A malformed connection string now fails when the data source is first resolved (UseDapperDataProtection() at startup) instead of at registration, as with the SQL Server provider.

Tests

• End-to-end Theory covering both registration orders: the application data source targets a non-existent database, the application still resolves its own instance, and the keys round-trip through the provider's table.
• Unit tests: no unkeyed NpgsqlDataSource registration; the data source is disposed with the service provider; the IncludeErrorDetail test now resolves the keyed instance.
• The new tests fail against the previous wiring (7 failures, both registration orders included).
• Release build clean; full suite 83/83.

Closes #19