Record-header primary button: honour Action.order and prioritize injected Approve/Reject

[os-zhuang]

Frontend companion to framework#2670 / framework#2682.

Problem

When a record is pending approval, the console injects Approve / Reject decision buttons for the approver. But the record-header renders only the first visible record_header action as the primary button and pushes the rest into the ⋯ overflow menu. Since app-defined actions (e.g. "申请关闭商机") typically register first, they take the primary slot and the approval decision the approver most needs is buried in overflow.

Framework side (done — framework#2682)

@objectstack/spec now has an explicit Action.order field (optional number, lower = higher / more prominent, default 0), and mergeActionsIntoObjects() stable-sorts every action group by it (both defineStack() and composeStacks()). Backward compatible: groups where nobody sets order keep their exact registration order.

Because this renderer currently picks the primary by array position, that framework sort already makes order effective for app-declared record-header actions. What remains is the objectui side for the dynamically injected approval buttons (which never pass through framework's merge).

objectui changes needed

1. Record-header primary selection — when choosing the primary button from the visible record_header actions, order them by:

   1. order ?? 0 (ascending, lower first)
   2. variant === 'primary' preferred (tie-break)
   3. original registration order (stable)

   …then take the first as primary and route the rest to the ⋯ overflow menu — instead of the current naive actions[0].

2. Injected Approve / Reject — when synthesizing the pending-approval decision buttons, give them a low default order (e.g. -100) and an appropriate variant (Approve → primary, Reject → secondary/danger) so the decision stably holds the primary slot for approvers, with app actions ordered after it (rather than the app having to hide its own actions to make room).

3. After merge, bump .objectui-sha in framework so the console build picks up the new renderer.

Acceptance

• On a pending-approval record (current user is approver): Approve is the primary button; app actions follow in the header/overflow; non-approval records and other toolbars are unchanged.
• Authors can set order on any record_header action to deterministically control the primary button without hiding siblings.

Refs framework#2670, framework#2682