fix multiple query params

fix: Allow custom Lambda events from SQS (laravel#194)

* fix: Allow custom Lambda events from SQS

When sending Lambda events from SQS to Vapor, it would always handle it as a Vapor Job as it only checked for the `messageId` in the event data, however, a Vapor Job also has always a `body->job` attribute as well. This way we can safely send custom Lambda events from SQS.

Before this fix, sending a custom event from SQS would cause the following:

```
  {
    "exception":{
      "class":"ErrorException",
      "message":"Undefined array key \"job\"",
      "code":0,
      "file":"/var/task/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php:356",
      "previous":{
        "class":"ErrorException",
        "message":"Undefined array key \"job\"",
        "code":0,
        "file":"/var/task/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php:251"
      }
    },
    "aws_request_id":"d88e2bb2-57ca-58e4-ae6b-4a8b65ea151f"
  }
```

 In addition to the main fix, I've also renamed a test fixture for clarity: `lambdaEvent.json` → `jobLambdaEventFromSQS.json` as it represents a SQS Job (it has both `messageId` and `body->job`). I've also added two other fixtures to represent SQS custom events and non-sqs custom events.

 Lambda Custom Events was "documented" at https://blog.laravel.com/vapor-trigger-the-cli-lambda-using-custom-events#:~:text=To%20extract%20the%20event%20payload%20from%20the,image%20is%20uploaded%20to%20an%20S3%20bucket

* Apply fixes from StyleCI

* fix: Allow custom Lambda events from SQS

When sending Lambda events from SQS to Vapor, it would always handle it as a Vapor Job as it only checked for the `messageId` in the event data, however, a Vapor Job also has always a `body->job` attribute as well. This way we can safely send custom Lambda events from SQS.

Before this fix, sending a custom event from SQS would cause the following:

```
  {
    "exception":{
      "class":"ErrorException",
      "message":"Undefined array key \"job\"",
      "code":0,
      "file":"/var/task/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php:356",
      "previous":{
        "class":"ErrorException",
        "message":"Undefined array key \"job\"",
        "code":0,
        "file":"/var/task/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php:251"
      }
    },
    "aws_request_id":"d88e2bb2-57ca-58e4-ae6b-4a8b65ea151f"
  }
```

 In addition to the main fix, I've also renamed a test fixture for clarity: `lambdaEvent.json` → `jobLambdaEventFromSQS.json` as it represents a SQS Job (it has both `messageId` and `body->job`). I've also added two other fixtures to represent SQS custom events and non-sqs custom events.

 Lambda Custom Events was "documented" at https://blog.laravel.com/vapor-trigger-the-cli-lambda-using-custom-events#:~:text=To%20extract%20the%20event%20payload%20from%20the,image%20is%20uploaded%20to%20an%20S3%20bucket

* Update CliHandlerFactory.php

---------

Co-authored-by: StyleCI Bot <bot@styleci.io>
Co-authored-by: Taylor Otwell <taylorotwell@gmail.com>

fix: Avoid Filtering Failed Jobs Timestamp in Memory (laravel#193)

* fix: Avoid Filtering Failed Jobs Timestamp in Memory

To display queue metrics, Vapor loads all `failed_jobs` and filters the period (1m, 5m, 10m, 30m, 1h, 24h, 7d, 30d) in memory.
When the failed_jobs table has a large number of rows, usually as a result of not pruning failed_jobs on a regular-basis, it would cause Queue Metrics to fail with HTTP status 502.

`getTable` was made public via laravel/framework#56384

Note: In another PR, we could also filter all the other filter options (id, queue, query)

* Update VaporQueueListFailedCommand.php

---------

Co-authored-by: Taylor Otwell <taylorotwell@gmail.com>

Add API Gateway request timestamp to server variables (laravel#192)

* Add API Gateway request timestamp to server variables

This PR adds support for extracting the original request timestamp from the API Gateway event (`requestContext.requestTimeEpoch` or `requestContext.timeEpoch`) and exposes it in the `$_SERVER` array as `AWS_API_GATEWAY_REQUEST_TIME`.

This enables more accurate request duration tracking and allows downstream code to calculate cold start latency by comparing the API Gateway arrival time to actual execution time.

The timestamp is derived directly from the incoming event and kept within the request context rather than being set as a global environment variable.
This keeps the data scoped to the request lifecycle and avoids side effects across concurrent executions.

If preferred, I’m happy to revise this to expose it via an environment variable or another mechanism.

* Satisfy code style requirements

* Update Request.php

---------

Co-authored-by: Taylor Otwell <taylor@laravel.com>

Merge pull request laravel#191 from laravel/flush-state

Add `flushState` method to reset static variables in `VaporWorkCommand`

set log_limit to 10kb

fix multiple query params

Support S3 compatible storage - e.g. herd minio (laravel#190)

Merge pull request laravel#187 from laravel-shift/l12-compatibility

Laravel 12.x Compatibility

Add explicit null for php 8.4 deprecation warning fix (laravel#188)