The event you want is controller_front_send_response_before, dispatched in Magento\Framework\App\Http::launch() right before the response is flushed. It passes the response object (Magento\Framework\App\Response\Http), and it fires late enough that the redirect status/headers are already set on the response but early enough that the Tideways profiler is still active — so renaming the transaction there takes effect.
Here's the full module. Drop it under app/code/Tideways/TransactionNaming/:
app/code/Tideways/TransactionNaming/
├── registration.php
├── etc/
│ ├── module.xml
│ └── events.xml
└── Observer/
└── SetRedirectTransactionName.php
A few notes:
The response object is Magento\Framework\App\Response\Http (extends the Laminas/PhpEnvironment response), so getStatusCode() is the canonical accessor. The method_exists guard is just cheap defense in case a controller ever hands back a non-HTTP response type on that event.
Result\Redirect::renderResult() calls setRedirect() which sets the status code via setHttpResponseCode(), so by the time this event fires getStatusCode() reliably returns 301/302. This also catches redirects that don't come from a Result\Redirect — e.g. URL-rewrite 301s — since they end up on the same response object.
Then bin/magento setup:upgrade && bin/magento cache:flush to register it.
One thing worth deciding: at global scope this fires on admin redirects too (lots of 302s after form saves). If you only want storefront redirects grouped under redirect, move events.xml to etc/frontend/.