PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

standardIssueToFormTreeError() walks a Standard Schema issue's path with target = target[pathKey]. When the last key is unknown to the model, target ends up undefined and the error falls back to the field being validated. When a key before the last one is unknown, the next step reads a property of undefined and errors() throws:

form(signal({name: ''}), (p) =>
  validateStandardSchema(p, z.object({name: z.string()}).superRefine((_, ctx) => {
    ctx.addIssue({code: 'custom', message: 'Wrong.', path: ['ghost', 'name']});
  })),
)().errors();
// TypeError: Cannot read properties of undefined (reading 'name')

Issue Number: #71128

What is the new behavior?

The path walk stops descending once it leaves the model (target?.[pathKey]), so the issue is reported on the field being validated, the same fallback that already applies when only the last key is unknown.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Added two tests to packages/forms/signals/test/node/api/validators/standard_schema.spec.ts: one for an unknown last key (existing behavior) and one for a path that runs through an unknown key. //packages/forms/signals/test/node:test passes locally (543 specs); without the fix the new test fails with the TypeError above.

An alternative would be to report the issue on the deepest existing field instead of the validated field. I kept the existing fallback for consistency, but happy to change it if preferred.

🤖 Generated with Claude Code