fix(components-native): Form respect safe area spacing

[omairJobber]

Summary

• wrap the Form body in a bottom SafeAreaView
• rely on safe-area insets instead of edge-to-edge-specific form spacing logic
• keep inline save button spacing aligned with the safe area

Before

buttonOverlapBefore.mp4

After

buttonOverlapAfter.mp4

Testing

• local Android verification in jobber-mobile against screens using Atlantis Form
• pre-commit checks (eslint and related jest tests)

[cloudflare-workers-and-pages]

Deploying atlantis with    Cloudflare Pages

Latest commit:	189ac41
Status:	✅  Deploy successful!
Preview URL:	https://51be801f.atlantis.pages.dev
Branch Preview URL:	https://job-159045-fixoverlap.atlantis.pages.dev

View logs

[Copilot]

Pull request overview

Adjusts the native Form layout to respect bottom safe-area insets more consistently, simplifying prior edge-to-edge spacing behavior and aligning action/inline save-button spacing with safe areas.

Changes:

• Wraps FormBody content in a bottom-only SafeAreaView (safe-area-context) instead of rendering a separate padding view.
• Removes edge-to-edge-specific conditional margin logic from Form.tsx and simplifies the inline save button bottom spacing condition.
• Updates safe-area rendering expectations in Form tests when saveButtonOffset is provided.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
packages/components-native/src/Form/components/FormBody/FormBody.tsx	Replaces container + conditional safe-area padding view with a bottom SafeAreaView; adjusts children typing.
packages/components-native/src/Form/Form.tsx	Removes edgeToEdgeEnabled dependency and simplifies inline save-button bottom margin condition.
packages/components-native/src/Form/Form.test.tsx	Updates safe-area rendering test to expect safe area even when saveButtonOffset is provided.

---

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

[Copilot]

useBottomPadding() now returns a constant 0, but it’s still used by Form to compute keyboard offsets and inline save-button spacing. This effectively disables any safe-area inset adjustment and can change behavior on devices with non-zero bottom insets. Consider either (a) re-implementing this using safe-area insets (e.g., via useSafeAreaInsets() / useScreenInformation().insets.bottom), or (b) removing the hook and simplifying the dependent calculations so they don’t rely on a dead value.

[Copilot]

This marginBottom branch is currently unreachable because paddingBottom comes from useBottomPadding(), which now always returns 0. If the intent is to keep inline save-button spacing aligned with the bottom safe area, paddingBottom needs to be sourced from safe-area insets (or the entire paddingBottom plumbing should be removed if SafeAreaView already guarantees the desired spacing).

[Copilot]

Test description is grammatically incorrect; consider rephrasing for clarity (e.g., remove the extra “is”).

Suggested change

	it("does render a safe area when there's a saveButtonOffset is provided", () => {
	it("does render a safe area when there's a saveButtonOffset provided", () => {

[Copilot]

saveButtonOffset is still declared on FormBodyProps, but FormBody no longer reads it (it isn’t destructured/used). This makes the prop misleading and easy to assume it still influences safe-area behavior. Either remove saveButtonOffset from FormBodyProps (and stop passing it from the parent), or re-introduce behavior that actually depends on it.