[PROPOSAL] Standardizing annotation-based data correction

Jakarta Validation defines a programming model for declaring and evaluating validation constraints.

I was recently working on a use-case where I had a requirement of both validating objects as well as correcting them based on some business rules - **automatically correcting data** before (or after) validation instead of only reporting violations.

Examples include:

* trimming whitespace
* assigning default values
* normalizing strings
* regex-based replacements
* custom corrections

To explore this idea, I built a working proof-of-concept library called [modak](https://github.com/akash-kansara/modak)

This project's APIs are heavily inspired by Jakarta Validation's concepts & APIs:

* annotation-based declarations
* extensible annotation
* groups and group sequences
* payloads
* nested object graph traversal
* container element support

Example of how data correction library can be used:

```java
public class User {
@Trim
@DefaultValue(strValue = "Anonymous")
public String name;

@DefaultValue(intValue = 18)
public Integer age;

public String role;

@RegexReplace(
regexPattern = "[^a-zA-Z0-9@._-]",
replaceStr = ""
)
public String email;

public User(String name, Integer age, String role, String email) {
this.name = name;
this.age = age;
this.role = role;
this.email = email;
}
}

User user = new User(" John Doe ", null, null, "example@com!pany.com");
corrector.correct(user);
System.out.println(user); // User{name='John Doe', age=18, role=null, email='example@company.com'}
```

## Why I'm opening this issue

I'm **not** proposing that Modak itself be adopted. Instead, I'd like to discuss whether **annotation-based data correction** belongs somewhere within the Jakarta ecosystem.

From my perspective there are two possibilities:

### 1. A future capability of Jakarta Validation

Data correction could become a standardized companion API to validation, sharing many of the same concepts (groups, sequences, metadata, object graph traversal, etc.).

### 2. A Jakarta sister project

If data correction is considered outside the scope of Jakarta Validation itself, it still seems like a natural Jakarta project because it builds directly on the same programming model and integrates closely with the Validation API.

## Why standardization might be valuable

A standardized API would encourage interoperability in the same way Jakarta Validation standardized validation itself.

I'd be interested in hearing thoughts on:

* Is annotation-based data correction considered within the vision of Jakarta Validation?
* If not, does it seem appropriate as a separate Jakarta project?
* Has this problem space been discussed previously?

The Modak implementation is intended as a proof of concept and API exploration rather than a proposal to standardize its current API unchanged.

Review the linked Modak proof-of-concept and the examples of annotation-based correction in this issue. Compare the idea with Jakarta Validation's existing programming model, then determine whether the outcome should be a Validation capability or a separate Jakarta sister project, with the scope and API direction agreed by the community.

Written by the indexing model from the issue text.