feat(APP-1053): Handle allowed actions based on chainid (6/10)

[milosh86]

Description

Restricts the actions offered by the action composer to the chain they will actually execute on, and
brings the allowed actions into the nested actions dialog so cross-chain payloads are composed
against the right allowlist.

An allowed action may now carry a chainId, because a single plugin condition can authorise actions
across several chains. IAllowedAction.chainId is optional and not guaranteed to be back-filled, so
an action without one is treated as an action of the DAO chain.

useAllAllowedActions

New query hook wrapping useAllowedActions, modelled on useAllDaoPermissions: it auto-paginates
every page and exposes the full list, keeping data undefined until the whole set is loaded so
consumers cannot act on a partial allowlist.

On top of that it filters by chain:

• chainId is optional — when it is not set, the actions of every chain are returned.
• The DAO chain is resolved from the network url param via networkDefinitions.
• An action without a chainId is only kept when the requested chain is the DAO chain
  ((action.chainId ?? daoChainId) === chainId).
• chainId is deliberately kept out of the request params, so the same plugin's actions are fetched
  and cached once instead of once per chain.

Nested actions dialog

The dialog now fetches the allowed actions itself and passes them down through
ProposalActionsEditor to ActionComposer. The two networks involved are different and are
sourced separately:

• the request targets the network of the plugin (the DAO network), which is where the plugin's
  allowed actions are indexed;
• the filter chainId comes from resolvedNetwork, the chain the nested actions are composed
  for.

So a cross-chain forward narrows the DAO-chain plugin's allowlist down to the destination chain, and
untagged (DAO-chain) actions correctly drop out of the offering.

INestedActionsDialogParams changed accordingly: daoId is now required, pluginAddress is new and
optional (no plugin means no allowlist and every action is offered), and network is re-documented —
it is the chain the actions are composed for, not the previous "use outside DAO context" escape
hatch.

Reaching the process plugin from an action component

ICreateProposalFormContext gains an optional processPlugin, populated in
createProposalPageClient where the plugin is already resolved. gov-ui-kit's
IProposalActionComponentProps only exposes action and index, and the render path forwards
nothing plugin-related, so the context is the only channel through which an arbitrarily nested custom
action component can learn which process it is being composed for.
CrossChainControllerForwardMessageAction reads it to pass pluginAddress into the dialog. It is
optional because ProposalActionsEditor mounts the same action components from the execute-actions
form and from the nested dialog, where no process plugin exists.

Fixes

• useAllowedActions ignored pageParam in its queryFn and always re-requested page 1. That made
  every "load more" in the DAO process allowed-actions list refetch the first page, and would have
  turned auto-pagination into an infinite loop.
• createProposalFormActions hand-rolled pages.flatMap with pageSize: 50 and no pagination, so
  it silently truncated at 50 allowed actions. It now uses the new hook.

Notes for reviewers

• ActionComposer infers "only offer authorized actions" from allowedActions != null
  (useState(allowedActions != null), read on first render). Passing [] therefore means "nothing
  is authorized", not "unrestricted" — which is why the call sites keep the value undefined when no
  plugin restricts the actions. For the same reason, if the composer mounts before the allowed
  actions have resolved it will offer every action for that mount; worth a look if the dialog should
  hold the composer back until the fetch settles.
• A disabled useAllAllowedActions query returns [] rather than undefined, so every call site
  guards the disabled case explicitly. Could be worth pushing into the hook.

Type of Change

• Minor: Feature (non-breaking change which adds new functionality)

Developer Checklist:

• Manually smoke tested the functionality in a preview or locally
• Confirmed there are no new warnings or errors in the browser console
• (For User Stories only) Double-checked that all Acceptance Criteria are satisfied
• Confirmed there are no new warnings on automated tests
• Merged and published any dependent changes in downstream modules
• Selected the correct base branch
• Commented the code in hard-to-understand areas
• Followed the code style guidelines of this project
• Reviewed that the Files Changed in Github's UI reflect my intended changes
• Confirmed the pipeline checks are not failing

Review Checklist:

• (For User Stories only) Tested in a preview or locally that all Acceptance Criteria are satisfied
• Confirmed that changes follow the code style guidelines of this project

[linear-code]

APP-1053

[github-actions]

🚀 Preview Deployment: View Here

[github-actions]

E2E results (preview)

Smoke

Base URL	https://app-next-9h1zf01br-aragon-app.vercel.app
Suite	smoke
Playwright result	✅ passed
Summary	82 passed
HTML report	View report
GitHub job	✅ completed

View run #4908