Limit BlueScreen agent argument dumps

[janlanger]

• bug fix / new feature? bug fix
• BC break? no
• doc PR: no

BlueScreen agent output currently dumps stack trace arguments without applying the same item and string limits that the HTML dump uses. In practice this can produce extremely large .md exception logs when a stack frame contains a large root array or object graph.

A real case was a hydration frame with a large result. The MD file grew to ~100 MB because the agent dump expanded the whole argument list.

This change fixes that in two parts:

• BlueScreen::getAgentDumper() now respects maxLength and maxItems
• stack trace arguments in agent.phtml are dumped with their argument name as the dumper key, so the existing Dumper::ITEMS limiting also applies to large root values

[jkuchar]

Independent confirmation of this, from production: we hit the same defect and filed #620 before finding this PR — closing that one as a duplicate. Two things from our side that may help move this along, because the impact is worse than a large .md.

It is a fatal, not just a big file. One stack frame holding a list of domain objects exhausted a 128 MB PHP-FPM worker inside Dumper/Describer.php. The worker dies, and the unrelated request it happened to be serving dies with it. Measured on Tracy 2.12.0 / PHP 8.5.7, N small objects in a single trace argument, peak memory the render allocates:

N	render() (HTML)	renderAgent() (.md)
5 000	27.37 MB total render, .md 681 kB	—
20 000	+2.01 MB, 148 kB output	+106.97 MB, 2.79 MB output
50 000	+3.89 MB, 148 kB output	+266.81 MB

With memory_limit=128M the process dies from ~22 000 objects. Turning BlueScreen::$maxDepth/$maxLength/$maxItems to the floor changes nothing, for exactly the reason this PR fixes: those values never reach the agent dumper.

Debugger::$reservedMemorySize does not save it, and enlarging it makes things worse. The reserve is released in shutdownHandler()/exceptionHandler(), so a bluescreen rendered from application code — ours goes through a Monolog handler bridging into Tracy\Logger during an ordinary request — never gets it. And since it is a plain string held for the whole request, raising it just lowers the threshold:

reserve	N=5 000	N=12 000	N=20 000
500 kB (default)	ok	ok	ok
8 MB	ok	ok	fatal
64 MB	ok	fatal	fatal

One residual this PR does not cover, in case it is worth a second commit: BlueScreen::findGeneratorsAndFibers() → Helpers::traverseValue() walks everything reachable from the exception with no depth or item limit at all, and runs before either template. With the markdown copy taken out of the picture entirely, our reproducer still dies at ~210 000 objects, inside Helpers.php. Much further out than the case this PR fixes, but structurally the same shape.

Happy to test a build of this against the original reproducer if that helps.

[spaze]

This also fixes a security bug, not just memory use.

Right now the .md log prints argument values that the .html log hides. Both #[SensitiveParameter] and keysToHide (including Tracy's own defaults like password and authorization) are silently ignored in agent.phtml, because isSensitive() is only reached for values that arrive with a key.

Btw, passing $name in this patch fixes the attribute but not keysToHide, because $name is '$' . $params[$k]->getName() and the lookup is by exact name, so $password never matches password. isSensitive() matches SensitiveParameterValue by type, which is why the attribute works with any key at all. Can send a followup PR.

In practice "just" stack arguments are affected, $_GET/$_POST and object properties are fine because those are array elements and object properties, so they have a key

A simple reproduction code for the security-side:

function connect(string $dsn, #[SensitiveParameter] string $password): never
{
    throw new RuntimeException('connection refused');
}

@mkdir(__DIR__ . '/log');
Debugger::enable(Debugger::Production, __DIR__ . '/log');
$password = 'hunter2-' . bin2hex(random_bytes(4));
try {
    connect('mysql:host=localhost', $password);
} catch (Throwable $e) {
    Debugger::log($e);
}

In the stack trace, the .html shows ***** (string), the .md shows value: 'hunter2-...'.