Resolve string enum parameters on the raw-SQL path

[dmytro-khmara]

Summary

• The relational type-mapping plugin only resolved a mapping when EF gave it both a CLR type and a store type. EF's raw-SQL parameter pipeline (DatabaseFacade.ExecuteSqlRaw{,Async}) supplies only the CLR type, so the plugin returned null, EF fell back to NpgsqlStringTypeMapping, and the parameter was pinned to NpgsqlDbType.Text — producing 42804: column "x" is of type my_enum but expression is of type text against any column of a native enum type.
• Adds an internal StringEnumPgTypeRegistry that the plugin consults when storeType is null, plus a configure overload on UseStringEnumsAsPostgresEnums that pre-registers each string enum.
• Pre-registration on the options builder is required because EF Core's relational type-mapping cache locks in the result of the very first FindMapping(typeof(TEnum), null) call, which fires during convention setup before OnModelCreating runs — model-level MapStringEnumAsPostgresEnum<TEnum>() is too late.

Usage

optionsBuilder
    .UseNpgsql(dataSource)
    .UseStringEnums()
    .UseStringEnumsAsPostgresEnums(r =>
        r.MapStringEnum<Sport>()
         .MapStringEnum<Status>(name: "status_kind", schema: "myapp"));

The configure delegate is optional — existing callers of UseStringEnumsAsPostgresEnums() keep working unchanged for the EF-translated path. It only needs to be supplied when raw-SQL parameter binding is required.

Test plan

• New integration test RawSqlEnumParameterTests.Binds_a_string_enum_parameter_in_ExecuteSqlRawAsync round-trips a Sport value through ExecuteSqlRawAsync against a real Postgres enum column. Fails on master with 42804, passes with this change.
• New unit test FindMapping_FallsBackToRegistry_WhenStoreTypeIsMissing pins the registry-fallback branch of the plugin.
• Existing integration round-trip and unit tests still green (25 unit + 3 integration).