Prevent Exception from getUri() in Cli-Context

[thegass]

Additionally check if we are running in cli.
Without it cli tasks which build a fake FE/BE Request fail.

fixes #121

[jpmschuler]

FWIW: to be more precise all cli exceptions will fail, no matter if there is a BE/FE request, so even unknown command fails:
Unknown command fails to during UriLookUp:

> vendor/bin/typo3 doesnt:exist
PHP Fatal error:  Uncaught TypeError: TYPO3\CMS\Core\Http\Request::getUri(): 
Return value must be of type Psr\Http\Message\UriInterface, null returned

[contemas-tschmidt]

Still present in 6.0.0, and the one-line change in this PR is the right fix. Fresh reproduction, in case it helps get this merged:

• TYPO3 14.3.6, networkteam/sentry-client 6.0.0, sentry/sentry 4.31.0, PHP 8.4

$ php vendor/bin/typo3 does-not-exist

  Request::getUri(): Return value must be of type Psr\Http\Message\UriInterface, null returned

State of the request at that moment, dumped from a shutdown function:

Environment::isCli():     true
TYPO3_REQUEST:            TYPO3\CMS\Core\Http\ServerRequest
ApplicationType:          BACKEND (isBackend=true)
Property $uri (raw):      NULL
getUri():                 TypeError

Two details that were new to me and may be useful for the issue:

The faking extension here is in2code/powermail. In2code\Powermail\Command\FakeRequestTrait creates (new ServerRequest())->withAttribute('applicationType', REQUESTTYPE_BE) — no URI. So the list of extensions doing this is longer than codingms/openimmo; @s-ude is right that it is an established pattern.

Why an unknown command triggers it reliably: typo3 list and ordinary commands do not show the problem, because the lazy command loader never constructs powermail's ExportCommand. For an unknown command, Symfony builds the alternatives list, which instantiates every command — and that constructor fakes the request. So the failure mode is not limited to scheduler tasks: it hits the "command failed" path, which is exactly when Sentry is supposed to help.

Worth stressing what the bug costs: the TypeError is thrown inside the global event processor while the SDK is capturing the original exception. The original error is neither printed nor sent — every CLI failure in an affected installation looks identical and no event reaches Sentry.

On the fix itself: checking !Environment::isCli() first is better than guarding setUrl(), because it also restores the request_type: cli tag. A try/catch around setUrl() would leave such events tagged backend.

We are shipping the equivalent behaviour downstream in the meantime by replacing Typo3Integration with our own integration in the integrations option for CLI only, and would happily drop that once this is released.