Use landscape-aware scrollable layout on Edit Agent and AI Rule pages

[MelvinBot]

Explanation of Change

On the Edit Agent instructions page and the Add/Edit AI Rule pages, the footer (Save/Delete) button was docked to the bottom of the screen and the multiline prompt input had no minimum height. In landscape orientation on iOS/Android this docked footer ate into the already-limited vertical space, making the input hard to see and use, and the page could not be scrolled to reach the full view.

AddAgentPage already solved this by deriving a shouldUseScrollableLayout flag from the device orientation and threading it through ScreenWrapper and FormProvider so that, in landscape, the footer joins the scroll content and the input keeps a minimum height. This change applies the exact same landscape-aware pattern to the three sibling pages that share the same form layout:

• src/pages/settings/Agents/Fields/EditPromptPage.tsx
• src/pages/workspace/rules/AIRules/AddAIRulePage.tsx
• src/pages/workspace/rules/AIRules/EditAIRulePage.tsx

On each page:

• Compute const shouldUseScrollableLayout = useIsInLandscapeMode() || (isMobile() && windowWidth > windowHeight);
• Pass shouldEnableMaxHeight={shouldUseScrollableLayout} to ScreenWrapper.
• Replace the hardcoded shouldUseScrollView={false} / submitFlexEnabled={false} on FormProvider with shouldUseScrollView={shouldUseScrollableLayout} / submitFlexEnabled={shouldUseScrollableLayout ? undefined : false}, so in landscape the footer renders inside the ScrollView and the whole page scrolls.
• Wrap the multiline input in a View that gets styles.minHeight42 only in landscape, giving the input a sensible minimum height.

Because the flag is false in portrait, the props collapse back to the current non-scroll / docked-footer / no-min-height behavior, so portrait is unaffected — only native landscape changes, as scoped in the issue.

Fixed Issues

$ #93182
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"

• Verify that no errors appear in the JS console

Offline tests

• Verify that no errors appear in the JS console

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...rc/pages/settings/Agents/Fields/EditPromptPage.tsx	70.73% <100.00%> (+2.31%)	⬆️
...rc/pages/workspace/rules/AIRules/AddAIRulePage.tsx	0.00% <0.00%> (ø)
...c/pages/workspace/rules/AIRules/EditAIRulePage.tsx	0.00% <0.00%> (ø)
... and 9 files with indirect coverage changes

[MelvinBot]

I analyzed the checks — there's no code failure to fix.

The only red check is PR Author Checklist / checklist, which fails because the checklist items in the PR description are still unchecked (and the ### Tests / ### QA Steps sections still have their // TODO placeholders). That check can only be cleared by the human co-author filling out those sections and ticking the boxes — it's not something a code change can resolve.

Everything substantive is green:

• test (job 1–8) ✅
• typecheck ✅ (also verified locally — no type errors in the three changed files)
• ESLint, Prettier, Check for unused styles ✅
• all build (...) jobs ✅

The baseline-perf-tests / branch-perf-tests jobs are still running but are informational comparisons, not blocking.

Next step: complete the Tests/QA Steps and PR Author Checklist in the description, then re-run the checklist check.