feat: prepare backend error messages for i18n

[fpindej]

Context

After #143, all client-facing error messages are static constants in ErrorMessages.cs nested classes (e.g. ErrorMessages.Admin.RoleNotFound). No interpolated runtime values leak to clients. This was an intentional design to make i18n extraction mechanical when the need arises.

Problem

The current const string approach only supports a single language. If the template is deployed in a multi-locale context, error messages need to be translatable.

Considerations

Several approaches exist — the issue is to evaluate and pick one when needed:

Approach	Pros	Cons
.resx resource files	Built-in .NET support, compile-time safety, satellite assemblies	Verbose XML, merge conflicts, no hot-reload
IStringLocalizer with JSON provider	Simpler file format, hot-reload possible	Loses compile-time key safety without a source generator
DB-backed via IStringLocalizer	Runtime editable, no redeployment	Adds DB dependency for error messages, caching complexity

Current state (good foundation)

• All messages are const string in ErrorMessages.cs — each is a natural translation key
• Nested class structure (Admin, Roles, User, Auth, ...) maps to resource file organization
• Zero interpolated strings in Result.Failure() calls — no format string complications
• Password validation errors are intentionally kept as Identity passthroughs (English-only from ASP.NET Identity unless Identity itself is localized)

Scope

• Choose an approach
• Replace const string lookups with localizable lookups (keep the same call-site ergonomics)
• Add a second locale (even a test locale) to validate the pipeline
• Decide whether to localize Identity password validation errors (requires IdentityErrorDescriber override)
• Update AGENTS.md error messages section with the new pattern

Not in scope

• Frontend i18n (already handled by the existing $lib/i18n setup)
• Localizing audit log messages or server-side log messages (these stay English for operational tooling)