feat: add copyable error reports to detailed exception pages

[memleakd]

Description

This PR proposes adding a Copy Details button to CodeIgniter’s detailed HTML exception page.

The goal is to make debugging information easier to share from the local development error page. Instead of manually gathering the relevant debugging information, users can copy a Markdown-formatted report with one click and paste it into an issue, discussion, chat, LLM or anywhere else they need.

Copy.Details.mp4

The copied report includes the most useful debugging context:

• Exception type, status code, status text, and message
• PHP, CodeIgniter, environment, SAPI, timestamp, and memory usage
• Request method, path, safe URL without query string, and user agent
• Source file location and nearby source lines
• Previous exceptions, when available
• Stack trace

The report intentionally avoids riskful or sensitive request data. It does NOT include headers, cookies, query strings, request body data, session data, route params, database queries, or trace arguments.

Implementation wise, the Markdown report is rendered by a small error_report.php partial used by the detailed HTML error view. The button uses the Clipboard API when available and falls back to a textarea-based copy path when needed.

Tests cover rendering the button, escaping the hidden report content, including previous exceptions, and omitting sensitive request data, trace arguments, and query strings from copied output.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[patel-vansh]

Really nice change. It will be really useful while debugging.

Just a thought. Maybe we could also supply which particular features are enabled/disabled. Like, CSRF enabled, CSP disabled, etc. so, in this way, we can debug more easily.

Also, we could also add route details too, like what is alias for this route, which controller method it corresponds to, which filters ran for these routes. And since this error page is only visible in dev environment and not in production, we can assume that revealing filter information or controller method can't be risky.

[neznaika0]

Right. It's safe in your dev environment. But this context will be shared with AI or third parties. I don't think we need 100% of the data in the response. Most of the errors are: syntax, connection, missing file.. The details of the application error depend on the developer.