feat(FormStore): support nested structures in form data handling

[willc001]

Closes NEXT_BUILDER-5249

依赖检查

组件之间的依赖声明，是微服务组件架构下的重要信息，请确保其正确性。

请勾选以下两组选项其中之一：

• 本次 MR 没有使用上游组件（例如框架、后台组件等）的较新版本提供的特性。

或者：

• 本次 MR 使用了上游组件（例如框架、后台组件等）的较新版本提供的特性。
• 在对应的文件中更新了该上游组件的依赖版本（或确认了当前声明的依赖版本已包含本次 MR 使用的新特性）。

提交信息检查

Git 提交信息将决定包的版本发布及自动生成的 CHANGELOG，请检查工作内容与提交信息是否相符，并在以下每组选项中都依次确认。

破坏性变更是针对于下游使用者而言，可以通过本次改动对下游使用者的影响来识别变更类型：

• 下游使用者不做任何改动，仍可以正常工作时，那么它属于普通变更。
• 反之，下游使用者不做改动就无法正常工作时，那么它属于破坏性变更。

例如，构件修改了一个属性名，小产品 Storyboard 中需要使用新属性名才能工作，那么它就是破坏性变更。
又例如，构件还没有任何下游使用者，那么它的任何变更都是普通变更。

破坏性变更：

• ⚠️ 本次 MR 包含破坏性变更的提交，请继续确认以下所有选项：
• 没有更好的兼容方案，必须做破坏性变更。
• 使用了 feat 作为提交类型。
• 标注了 BREAKING CHANGE: 你的变更说明。
• 同时更新了本仓库中所有下游使用者的调用。
• 同时更新了本仓库中所有下游使用者对该子包的依赖为即将发布的 major 版本。
• 同时为其它仓库的 Migrating 做好了准备，例如文档或批量改动的方法。
• 手动验证过破坏性变更在 Migrate 后可以正常工作。
• 破坏性变更所在的提交没有意外携带其它子包的改动。

新特性：

• 本次 MR 包含新特性的提交，且该提交不带有破坏性变更，并使用了 feat 作为提交类型。
• 给新特性添加了单元测试。
• 手动验证过新特性可以正常工作。

问题修复：

• 本次 MR 包含问题修复的提交，且该提交不带有新特性或破坏性变更，并使用了 fix 作为提交类型。
• 给问题修复添加了单元测试。
• 手动验证过问题修复得到解决。

杂项工作：

即所有对下游使用者无任何影响、且没有必要显示在 CHANGELOG 中的改动，例如修改注释、测试用例、开发文档等：

• 本次 MR 包含杂项工作的提交，且该提交不带有问题修复、新特性或破坏性变更，并使用了 chore, docs, test 等作为提交类型。

[codecov]

Codecov Report

❌ Patch coverage is 91.48936% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.01%. Comparing base (c0b0701) to head (127ae78).

Files with missing lines	Patch %	Lines
shared/form/src/FormStore.ts	91.48%	1 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #498      +/-   ##
==========================================
+ Coverage   74.98%   75.01%   +0.02%     
==========================================
  Files         607      607              
  Lines       18764    18778      +14     
  Branches     2894     2897       +3     
==========================================
+ Hits        14071    14087      +16     
+ Misses       4150     4146       -4     
- Partials      543      545       +2     

Files with missing lines	Coverage Δ
shared/form/src/FormStore.ts	76.25% <91.48%> (+3.64%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🚀 Deployed on https://docs-preview-498--next-advanced-bricks.netlify.app

[github-actions]

📐🤏 Size check result (c0b0701...0777175):

error code: 1033

[Copilot]

Pull request overview

This PR adds support for nested object and array structures in FormStore's form data handling, transitioning from flat field access to lodash path-based operations (get/set/has/unset). The implementation also introduces filtering for fields marked with notRender.

Key changes:

• Replace direct property access with lodash path-based methods to support nested field names like "user.name" and "items[0].name"
• Add notRender field filtering across all data access methods
• Update validation logic to handle nested data structures

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
shared/form/src/FormStore.ts	Core implementation changes to support nested structures using lodash path methods, add notRender filtering, and update validation type signatures
shared/form/src/FormStore.spec.ts	Add comprehensive tests for nested object/array structures and notRender field handling, update existing test expectations to match new behavior

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[weareoutman]

之前有个 allFields 的过滤，这个逻辑不需要了？

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When parseFloat(value) is called on a non-numeric string, it returns NaN. The subsequent comparisons numberValue < min and numberValue > max will always be false when numberValue is NaN, which means invalid numeric strings would silently pass validation.

Consider adding a check for NaN after parsing:

const numberValue = typeof value === "number" ? value : parseFloat(value);
if (isNaN(numberValue)) {
  return messageBody(message?.pattern || `${label}必须是有效的数字`);
}

Suggested change

	typeof value === "number" ? value : parseFloat(value);
	typeof value === "number" ? value : parseFloat(value);
	if (isNaN(numberValue)) {
	return messageBody(message?.pattern || `${label}必须是有效的数字`);
	}