fix(providers/aws): restore main's fulfillment_final semantics for INSTANT + RunInstances

The earlier revert overshot: it set ``fulfillment_final=True`` uniformly
across every AWS handler, but the main-equivalent semantics differ per
provider.  ``fulfillment_final=True`` means the CREATE call returned the
entire fulfilment story synchronously, so the dispatch layer can stamp
COMPLETED immediately when len(instances) >= count.

- EC2Fleet REQUEST / MAINTAIN: ``True`` — create returns only a fleet ID
  and no instances; nothing more is coming synchronously.  (Unchanged
  from the earlier revert.)
- EC2Fleet INSTANT: ``False`` — create returns instance IDs but the
  instances are still in ``pending`` state at create time; the polling
  loop has to observe the running transition.
- RunInstances: key omitted (defaults to False) — instance IDs are
  synchronous, instance state is not.

INSTANT and RunInstances were both wrong on the revert: they ended up
with ``fulfillment_final=True``, so dispatch tried to mark the request
COMPLETED at provisioning time before instances were actually running.
SpotFleet and ASG keep ``True`` because their create calls return zero
instances synchronously — the same shape as a REQUEST/MAINTAIN fleet.

Note that this fix does NOT resolve all live test failures we saw in
the latest run.  AWS eu-west-2 is currently delivering only 2 of 4
t3.medium INSTANT instances, so the request correctly settles at
``state="partial"`` (HF wire: complete_with_error) for the 4-capacity
test scenarios.  That is a real AWS capacity flake against the test
suite's assertions, not a code bug.

Author: fgogolli

src/orb/providers/aws/infrastructure/handlers/ec2_fleet/handler.py

@@ -189,14 +189,17 @@ def _acquire_hosts_internal(
                     "resource_type": "ec2_fleet",
                     "fleet_type": fleet_type_value,
                     "fleet_errors": fleet_errors,
-                    # ``fulfillment_final`` reports whether the provider's
-                    # CREATE call is the final word from the provisioning
-                    # layer.  All fleet types return a stable fleet ID at
-                    # create time; whether instances are actually running is
-                    # a separate ``check_hosts_status`` polling concern that
-                    # drives the request from IN_PROGRESS to COMPLETED.  See
-                    # ``fulfilment-model.md`` for the two-layer design.
-                    "fulfillment_final": True,
+                    # ``fulfillment_final=True`` means the provider's CREATE
+                    # call returned the entire fulfilment story synchronously.
+                    # MAINTAIN / REQUEST fleets return only a fleet ID and no
+                    # instances yet (instance arrival is purely a polling
+                    # concern), so the create call IS the final synchronous
+                    # answer for those types.  INSTANT fleets return instance
+                    # IDs synchronously but those instances are still in
+                    # ``pending`` state at create time, so the create call is
+                    # NOT the final answer — the polling loop must observe the
+                    # running state.  Matches the pre-redesign main semantics.
+                    "fulfillment_final": fleet_type is not AWSFleetType.INSTANT,
                     "capacity_constrained": capacity_constrained,
                 },
             }

src/orb/providers/aws/infrastructure/handlers/run_instances/handler.py

@@ -143,11 +143,13 @@ def _acquire_hosts_internal(
                     "resource_type": "run_instances",
                     "reservation_id": resource_id,
                     "instance_ids": instance_ids,
-                    # RunInstances returns instance IDs synchronously.  The
-                    # provider create-call is final; instance running-state
-                    # is driven by check_hosts_status from IN_PROGRESS to
-                    # COMPLETED on the polling layer.
-                    "fulfillment_final": True,
+                    # RunInstances returns instance IDs synchronously but the
+                    # instances themselves are still ``pending`` at this
+                    # point.  Omitting ``fulfillment_final`` defaults it to
+                    # False at the dispatch layer, which routes the request
+                    # through the polling loop so check_hosts_status can drive
+                    # IN_PROGRESS → COMPLETED once instances reach ``running``.
+                    # Matches the pre-redesign main semantics.
                 },
             }
         except Exception as e: