refactor(dal): unblock EF Core migration generation — ProjectVDbContext model validation

[Vasar007]

Summary: EF Core 10's model validator rejects ProjectVDbContext at first access — MigrateAsync, EnsureCreatedAsync, and any LINQ / raw-SQL query through DbSet all hit the same validator:

The 'RefreshTokenDbInfo' property 'UserDbInfo.RefreshToken' could not be mapped because the database provider does not support this type.

UserDbInfoConfiguration.Configure mapped a navigation-typed property (RefreshTokenDbInfo? RefreshToken) as an EF scalar via builder.Property(e => e.RefreshToken). The reverse fix — builder.Ignore or [NotMapped] — surfaces a follow-on binding error because the only constructor on UserDbInfo takes RefreshTokenDbInfo? refreshToken, and EF's constructor binder cannot bind a navigation parameter to a mapped scalar.

A partial fix landed during Phase 2 at the UserDbInfo ctor level (a 6-arg internal ctor that EF can bind + [NotMapped] on the RefreshToken property) — enough to make the test-side raw-SQL channel viable, but NOT enough to make migration generation work.

Where

• Sources/Libraries/ProjectV.DataAccessLayer/Services/Users/UserDbInfoConfiguration.cs — the Configure method.
• Sources/Libraries/ProjectV.DataAccessLayer/Services/Users/Models/UserDbInfo.cs — constructor shape + the [NotMapped] partial fix.
• Sources/Libraries/ProjectV.DataAccessLayer/Services/Tokens/Models/RefreshTokenDbInfo.cs — WrappedUserId is never assigned by any ctor (always default(UserId)).
• Sources/Libraries/ProjectV.DataAccessLayer/Migrations/.gitkeep — placeholder for the future InitialCreate migration once the model is clean.
• Sources/WebServices/ProjectV.ProcessingWebService/Program.cs — currently calls EnsureCreatedAsync guarded by CanUseDatabase=false in appsettings.json; the production schema story.

Workaround in place (test-side only)

The Phase 2 DAL integration suite bypasses EF entirely — Sources/Tests/ProjectV.DataAccessLayer.Tests/ForTests/DbCollectionFixture.cs issues raw CREATE TABLE statements through Npgsql.NpgsqlConnection directly; the per-test TRUNCATE flows through the same channel. The dotnet-ef 10.0.8 tooling + ProjectVDbContextDesignTimeFactory : IDesignTimeDbContextFactory<…> are installed and committed so the next attempt at dotnet ef migrations add InitialCreate can run without re-bootstrapping.

Decisions needed before unblocking

1. Should UserDbInfo.RefreshToken be removed entirely (the live token row lives in tokens keyed on RefreshTokenDbInfo.UserId) OR turned into an explicit HasOne()...WithOne() relationship?
2. What to do with RefreshTokenDbInfo.WrappedUserId — currently always default(UserId) because no ctor assigns it.
3. Does the production app keep EnsureCreatedAsync as its schema story, or move to migrations?

Acceptance

• dotnet ef migrations add InitialCreate succeeds against ProjectVDbContext and produces an InitialCreate migration class under Sources/Libraries/ProjectV.DataAccessLayer/Migrations/.
• DbCollectionFixture.ApplySchemaAsync in ProjectV.DataAccessLayer.Tests flips from raw-SQL bootstrap to Database.MigrateAsync() (or EnsureCreatedAsync, whichever the production app uses); existing Testcontainers integration tests continue to pass.
• RefreshTokenDbInfo.WrappedUserId either gets assigned in the ctor OR is removed.
• The follow-up rename migration for tokens.user_name → tokens.user_id (refactor(dal): rename tokens.user_name column to tokens.user_id (stores Guid, not name) #340) becomes naturally addressable; the token-uniqueness decision (refactor(dal): clarify token uniqueness — UNIQUE constraint on tokens.user_name + SingleOrDefaultAsync #339) can be applied as a schema constraint in the same migration generation pass.

Surfaced by

Phase 2 Test Coverage (milestone v0.9.8) — DAL integration slice on ProjectV.DataAccessLayer.Tests. Companion to #339 (token-uniqueness decision) and #340 (tokens.user_name rename, which is blocked on this unblocking).

[Vasar007]

Follow-up note from PR #342 review

Once the first EF Core migration class is committed under Sources/Libraries/ProjectV.DataAccessLayer/Migrations/, remove the placeholder file Sources/Libraries/ProjectV.DataAccessLayer/Migrations/.gitkeep. The placeholder exists today only because the directory must ship in git for the migration target path to resolve when no migrations have been generated yet. After a real migration class lands in that directory, the .gitkeep is redundant and should be deleted in the same change.

[Vasar007]

Follow-up note from PR #342 review

When the DAL model layer is next touched, refactor the model classes (UserDbInfo, RefreshTokenDbInfo, and any other models that currently use constructor-only immutability) to drop the constructor and use { get; init; } properties instead.

Motivation: init is not a style preference — it is required so EF Core (when materialising entities from the database), ASP.NET configuration binding (when reading appsettings into typed records), and standard serialization (System.Text.Json / Newtonsoft.Json round-tripping) can write properties at construction time while the model remains immutable post-construction. The current constructor-based pattern works for the PR #342 scope as a stop-gap; the longer-term shape is { get; init; }.

Scope of the future refactor:

• Replace ctor-only immutability with { get; init; } on every DAL model.
• Confirm round-tripping continues to pass the schema-shape tests.
• Confirm EF Core entity materialisation still works (currently exercised by the integration tests using the Postgres test container).