Pull Request Checklist

• Have you added new tests to prevent regressions?
  No — this change is a typing/runtime alignment; existing tests pass. I can add a test if maintainers want one.
• If a documentation update is necessary, have you opened a PR to the docs repo?
  No — not required for this small typings fix.
• Did you update the typescript typings accordingly (if applicable)?
  Yes — updated ValidationErrorItemType and the constructor behavior so generated .d.ts matches runtime.
• Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
  No issue link — described the problem below.
• Does the name of your PR follow our conventions?
  Yes — fix(types): align ValidationErrorItem typings with runtime (v6 backport).

Description of Changes

The published v6 package shipped .d.ts with lowercase enum keys while runtime throws capitalized type strings (e.g. "notNull Violation", "Validation error"). This caused a mismatch for TypeScript consumers.

This PR backports a minimal, safe fix for v6:

• Update ValidationErrorItemType enum to use the canonical runtime keys (so generated .d.ts reflects what is actually thrown).
• Make ValidationErrorItem constructor accept type strings case-insensitively and preserve the original passed form in this.type, while mapping to the canonical origin value internally.

Files changed:

• packages/core/src/errors/validation-error.ts (enum + constructor logic)

Behavior:

• Runtime behavior unchanged (tests still expect capitalized runtime strings).
• Generated .d.ts now matches runtime values, so TypeScript consumers on v6 get correct typings.
• Backwards-compatible with older clients that used lowercase strings.

List of Breaking Changes

• None. This is a backwards-compatible typing/runtime alignment.

Testing / How I verified

Locally:

yarn install --immutable
yarn build
yarn test

If you prefer, I can add a small unit/integration test asserting ValidationErrorItem.type for the specific cases; otherwise this remains a focused, low-risk backport.

If you want I can also attach the diff -u output (pack vs. built) to the PR comments.