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

packages/form-core/src/utils.ts の isFieldInGroup から始め、次に packages/form-core/src/FormGroupApi.ts の getRelatedFields() と packages/form-core/src/FieldApi.ts の validate() を調べます。関連する form-core テストを実行し、無関係な username フィールドと並んで user という名前のグループを対象とするカバレッジを追加します。グループ操作とバリデーションに無関係なフィールドが含まれなくなれば完了です。

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().