Summary

Ensure that approved motions in the federated-authority pallet are always removed from on-chain storage after motion_close, regardless of whether the dispatched call succeeds or fails. Adds test coverage for the failure scenario and removes dead error variants.

🎫 Ticket 📐 Engineering

Motivation

The motion_close extrinsic in the federated-authority pallet used motion_result? to propagate dispatch errors after calling motion_remove. While this appeared to work, the #[pallet::call] transactional storage layer rolls back all mutations when the extrinsic returns Err — including the motion removal. This left motions with failing dispatches permanently stuck in storage with no recovery path, as identified by the Least Authority security audit (PM-19974).

Changes

• Dispatch error handling — Remove motion_result? from the approved branch of motion_close. The dispatch outcome is captured in the MotionDispatched event; the extrinsic returns Ok regardless of dispatch success since the close operation itself (removal + events) always succeeds.
• Test coverage — Add motion_close_removes_motion_on_failed_dispatch test that creates an approved motion with a Root-failing call (pallet_collective::Call::vote), closes it, and verifies the motion is removed and correct events are emitted.
• Dead code cleanup — Remove 3 unused error variants (MotionTooEarlyToClose, MotionAlreadyExists, MotionExpired) that were never constructed.

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason: audit fix, no new features
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• No new todos introduced

🔱 Fork Strategy

• Node Runtime Update
• Node Client Update
• Other
• N/A

🗹 TODO before merging

• Ready for review