FIX: Give scenario end-to-end tests time to start a scenario

[varunj-msft]

Description

Scenarios in the end-to-end suite have been failing with an empty Error starting scenario: message.

Starting a scenario is a single request, and the server does the work before it answers: it runs the initializers, including loading each scenario's default datasets, resolves the target, and builds the scenario. That work grows with the number of registered scenarios and now exceeds the client's default read timeout of 60 seconds, so the client gives up while the server is still preparing the run. The message is empty because the underlying read timeout stringifies to nothing, so the report names neither the request that expired nor the timeout that governed it.

The timings confirm which timeout expired. Attempts are 150 seconds apart, which is the 60 second read timeout plus the 90 second delay between the flaky reruns, and the final attempt fails exactly 60 seconds after it starts because no delay follows it. The server answers other requests in the same session: the dataset tests pass before any scenario runs.

This passes an explicit, larger read timeout so the client waits for the setup it asked the server to do. It does not shrink the setup work itself — reducing what the default dataset initializer loads is still worth doing on its own, and would not remove the need for this timeout: measured locally with the large package registries excluded, the same setup still takes around seventy seconds, above the sixty second default.

Tests and Documentation

Test-only change to tests/end_to_end/test_scenarios.py; no product code is touched, and the --request-timeout option it passes already exists in pyrit_scan. The meaningful check is a live end-to-end run, which I plan to queue once this is on main, since that pipeline is scheduled only on main.

No notebooks are affected, so JupyText was not run.