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

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.

Start by reading src/Http/Response.php, src/Http/Traits/Response, src/Http/Helpers/http.php, and src/App/Enums/ReservedKeys.php to understand existing redirect and old-input behavior. Trace the current referrer fallback usage and define the response-level API and no-referrer fallback before changing helpers. Done means back-navigation support exists, helper behavior remains coherent, and redirectWith() still preserves old-input/session behavior.