Add back() support to the response redirect API and align redirect helpers around it

Inizia leggendo src/Http/Response.php, src/Http/Traits/Response, src/Http/Helpers/http.php e src/App/Enums/ReservedKeys.php per comprendere il comportamento esistente dei redirect e di old-input. Traccia l’utilizzo attuale del fallback del referrer e definisci l’API a livello di risposta e il fallback senza referrer prima di modificare gli helper. Il lavoro è completo quando esiste il supporto alla navigazione all’indietro, il comportamento degli helper rimane coerente e redirectWith() continua a preservare il comportamento di old-input/sessione.

Summary

Add first-class “go back” support to the HTTP response redirect API.

The goal is to stop repeating manual referrer fallback patterns such as redirect(get_referrer() ?? base_url()) and provide a cleaner redirect-back flow through the response layer.

Why

The current HTTP helper surface already supports:

• redirect(string $url, int $code = 302)
• redirectWith(string $url, array $data, int $code = 302)
• get_referrer()
• old(string $key)

But the codebase repeatedly uses manual “back” logic such as:

• redirect(get_referrer() ?? base_url())
• redirectWith(get_referrer() ?? base_url(), $data)

This creates repeated fallback logic in controllers, middlewares, and templates, and it exposes redirect implementation details at call sites instead of making “go back” a first-class response capability.

Goal

Introduce a clear back() redirect flow at the response/API level and align helper usage around it.

Proposed Direction

Add response-level back redirect support

Add a response API for redirecting back, with a defined fallback behavior when no referrer is available.

The exact shape can be decided during implementation, but it should support a response-first flow such as:

• response()->back()
• or response()->redirect()->back()

Preserve helper convenience where appropriate

If helper compatibility is desired, provide helper-level support that delegates to the response API rather than keeping manual fallback patterns spread throughout the codebase.

Examples of the intended cleanup direction:

• redirect(get_referrer() ?? base_url())
• redirectWith(get_referrer() ?? base_url(), $data)

should become a cleaner first-class back-navigation API.

Define fallback behavior explicitly

The implementation should define what happens when no referrer exists.

A sensible default appears to be current behavior:

• fallback to base_url()

but this should be an intentional contract rather than repeated ad hoc logic.

Keep old-input behavior aligned

Current redirectWith() behavior stores previous request data in session for later retrieval via old().

The new back-navigation flow should be designed so old-input redirect behavior remains coherent and can fit naturally into the redirect API.

Acceptance Criteria

• response-level back-navigation redirect support exists
• manual referrer fallback patterns are no longer required for common “go back” redirects
• fallback behavior when no referrer exists is explicitly defined
• helper-level redirect behavior remains coherent with the response API
• current old-input/session redirect behavior remains supported
• the resulting API is suitable for follow-up cleanup of templates and generated module code

Notes

Relevant code:

• src/Http/Helpers/http.php
• src/Http/Response.php
• src/Http/Traits/Response
• src/App/Enums/ReservedKeys.php

Examples of current repeated usage exist across module templates, controllers, and middlewares.

This ticket should come before the follow-up cleanup ticket that updates templates to prefer the new response redirect style.