FormGroupApi.getRelatedFields and FieldApi.validate() use unguarded startsWith for group membership, matching unrelated fields with a shared name prefix

Start with isFieldInGroup in packages/form-core/src/utils.ts, then inspect getRelatedFields() in packages/form-core/src/FormGroupApi.ts and validate() in packages/form-core/src/FieldApi.ts. Run the relevant form-core tests and add coverage for a group named user alongside an unrelated username field; done means group operations and validation no longer include the unrelated field.

I found another instance of the string-prefix bug that #2318 just fixed for deleteField.

FormApi.deleteField used to select sub-fields with a raw f.startsWith(fieldStr), which meant deleting field email also deleted the unrelated sibling emailVerified (#2317). That was fixed in #2318 by requiring a . or [ boundary after the prefix, and packages/form-core/src/utils.ts now has a proper isFieldInGroup(groupName, fieldName) helper that does the same boundary check for FormGroups:

export function isFieldInGroup(groupName: string, fieldName: string) {
  return (
    fieldName === groupName ||
    fieldName.startsWith(`${groupName}.`) ||
    fieldName.startsWith(`${groupName}[`)
  )
}

I checked where FormGroups associate fields with themselves and found two places that don't use this helper and still do the raw unguarded startsWith:

1. FormGroupApi.getRelatedFields() (packages/form-core/src/FormGroupApi.ts, around line 1649):

if (field.instance.name.startsWith(this.name)) {
  relatedFields.push(field.instance)
}

2. FieldApi.validate() (packages/form-core/src/FieldApi.ts, around line 1628), when computing which groups "encompass" a field:

const encompassingGroups = opts?.skipGroupValidation
  ? []
  : Array.from(this.form.formGroupApis).filter((group) =>
      this.name.startsWith(group.name),
    )

I confirmed getRelatedFields() isn't just informational, it's used by validate(), validateAllFields(), areRelatedFieldsValid(), and handleSubmit() on FormGroupApi to decide which fields belong to the group, get touched on submit, and get counted toward the group's validity.

Repro: a form with a FormGroup named user and an unrelated top-level field named username. Submitting the user group marks username as touched and includes its validity in areRelatedFieldsValid(), even though username isn't nested under the group at all. Similarly, changing username makes FieldApi.validate() treat the user group as "encompassing" it and rerun that group's form-level validators on every change to username.

I compared this against isFieldInGroup in utils.ts, which already has the correct fix, and against getRelatedFieldMetasDerived() in the same FormGroupApi.ts file, which does use isFieldInGroup correctly (lines 1671, 2314, 2334). So the fix pattern already exists in the codebase, it's just not applied consistently at the two call sites above.

Suggested fix: swap both raw startsWith checks for isFieldInGroup(this.name, field.instance.name) in getRelatedFields() and isFieldInGroup(group.name, this.name) in FieldApi.validate().