Step Order value for Post Steps can be incorrect if a job contains composite actions

Describe the bug
We provide an Order field on steps that dictate what order the steps ran in , this helps the UI populate the step order. For jobs with a composite action and a number of post job steps, occasionally that order field can collide on post steps. This is not intentional, but is typically handled by server side code to figure out what order the steps should be in.

To Reproduce
Create an action in local_action/action.yml

name: test
description: test
runs:
  using: composite
  steps:
    - name: ok
      shell: bash
      run: |
        echo "OK"

Create a workflow

name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:

jobs:
  build:
    runs-on: [ self-hosted ]
    steps:
      - uses: actions/checkout@v2
      - uses: ./local_action
      - uses: actions/setup-node@v2

Both of the post steps with end with order: 10, this is because our composite action handler is actually iterating the order on steps despite it not being a step with a timeline record that is sent back to the server. We should probably use a dummy childTimelineRecord order for Embedded steps to fix this.

Expected behavior
A clear and concise description of what you expected to happen.

Runner Version and Platform

2.287.1
All OS

Start at src/Runner.Worker/ExecutionContext.cs around line 336, where composite action handling iterates step order. Verify how embedded steps without timeline records affect post-step ordering, then ensure post steps receive distinct order values instead of colliding; the reproduction workflow provides the completion check.