feat: add property path transformation

This resolves #3 to allow custom property paths to be defined.

src/request.validation/package-readme.md

@@ -7,6 +7,8 @@
 - **Structured validation output:** Each failure is returned as a `Problem` with a property path, message, severity,
   code, and attempted value.
 - **Nested validation:** Reuse validators for complex object graphs with `SetValidator`, including DI-based resolution.
+- **Configurable paths:** Rewrite or remove rule property paths when the reported path should differ from the CLR
+  member path.
 
 ## Getting Started
 
@@ -65,6 +67,29 @@ public sealed class CreateUserRequestValidator : Validator<CreateUserRequest>
   }
 }
 
+public sealed record LoginInput(string? Username);
+
+public sealed record LoginRequest(LoginInput Input);
+
+public sealed class LoginInputValidator : Validator<LoginInput>
+{
+  public LoginInputValidator()
+  {
+    RuleFor(input => input.Username)
+      .NotEmpty();
+  }
+}
+
+public sealed class LoginRequestValidator : Validator<LoginRequest>
+{
+  public LoginRequestValidator()
+  {
+    RuleFor(request => request.Input)
+      .WithoutPropertyPath()
+      .SetValidator(new LoginInputValidator());
+  }
+}
+
 var validator = new CreateUserRequestValidator();
 var validation = validator.Validate(new CreateUserRequest(
   Name: "",
@@ -80,3 +105,6 @@ foreach (var problem in validation.Problems)
 
 The resulting `Problem` entries include full property paths like `Address.Street` and `Tags[0]`, making it easy to
 surface validation errors back to callers or APIs.
+
+If the validation path needs to differ from the CLR property path, use `WithPropertyPath(...)` for a custom transform
+or `WithoutPropertyPath()` to drop the current rule path entirely before nested paths are appended.