feat(resources): add ProjectV.Resources assembly and extract user-visible strings

[Vasar007]

Summary

Add a dedicated ProjectV.Resources library project and migrate inline user-visible strings (exception messages, log messages with user-facing wording, validation messages, error reasons) out of the per-feature libraries into a single resource project. This is a refactor — no behavioural change, no new feature surface area.

Motivation

Inline string literals are scattered across the data access layer, web services, and Telegram bot code. Centralising them in a single resource project gives us:

• A single place to localise the strings if/when localisation is added.
• Cleaner separation between behaviour-bearing code and human-readable wording.
• Easier audit of what messages the user actually sees (vs. internal diagnostic logs).

Initial scope

• New project: Sources/Libraries/ProjectV.Resources/ProjectV.Resources.csproj, targeting net10.0, no Windows-only deps so it ships in Linux x64.
• Public static class(es) per resource family (e.g. DataAccessMessages, ValidationMessages, RetryMessages).
• Migrate exception message literals from Sources/Libraries/ProjectV.DataAccessLayer/ first (this is what the linked PR review thread anchored on — see Sources/Libraries/ProjectV.DataAccessLayer/ProjectVDbContextDesignTimeFactory.cs).
• Follow-up batches: web services, Telegram bot, and any other user-visible string holdouts.

Out of scope

• No localisation infrastructure (resx-based satellite assemblies) in the first iteration. Plain public static readonly string constants are enough until a real localisation requirement arrives.
• No CLI / console message migration unless an exception bubbles through a user-visible surface.

Acceptance criteria

• ProjectV.Resources project exists, builds clean on x64 and Linux x64.
• All exception messages thrown from Sources/Libraries/ProjectV.DataAccessLayer/ reference a constant in ProjectV.Resources (no inline literals in throw new …(…) calls).
• At least one unit test verifies the resource constants are non-empty (smoke test) — see dotnet-backend-dev:create-tests conventions for shape.
• No regression in the existing test suite.

Tracking

Surfaced during PR #342 code review (anchor thread: T#3294330454).