Preserve named patterns when --update rewrites a failing block

Comienza con la implementación actual de buildUpdatedBlock() y revisa el plan activo de expansión de comodines para la integración en update-mode. Reproduce el fallo con el ejemplo de markdown proporcionado y, después, sigue la correspondencia entre la salida esperada y los patrones con nombre. Se considera terminado cuando las actualizaciones de texto estables funcionan mientras se conservan los patrones con nombre coincidentes, los casos ambiguos muestran una advertencia y una ejecución normal posterior pasa correctamente.

Summary

tryscript run --update replaces the entire expected-output section of each failing block with literal output. If that block contains named patterns for values such as a sandbox path, timestamp, PID, or allocated byte count, the update silently turns them into one run's concrete values. The next ordinary run then fails even when the intended stable-output update was correct.

This makes the documented update-and-compare workflow unsafe for realistic golden files that intentionally retain named patterns.

Observed with tryscript 0.1.7. The current buildUpdatedBlock() implementation writes result.actualOutput directly, so this appears to be current behavior rather than a platform-specific failure.

Minimal Reproduction

---
patterns:
  PID: '\d+'
---

# Mixed Stable and Unstable Output

```console
$ node -e "console.log('status: new'); console.log('pid: ' + process.pid)"
status: old
pid: [PID]
? 0

Run:

```console
tryscript run --update example.tryscript.md
tryscript run example.tryscript.md

The first command rewrites the block to a literal PID. The second command fails when Node has a different PID.

A concrete downstream case changed fixture names and stable byte totals in CLI transcripts containing [SCAN_PATH], [MTIME_NS], and [ALLOCATED]. --update replaced all three pattern classes with literals across every changed block, and the mandatory comparison failed on the next sandbox.

Desired Behavior

When updating a structurally corresponding block:

• update stable text that no longer matches
• preserve named patterns where the old expected output used them and the corresponding new value still matches that pattern
• make an immediate ordinary rerun pass
• warn clearly instead of silently literalizing a named pattern when correspondence is ambiguous
• retain an explicit opt-in such as --expand-all for users who do want named patterns replaced by concrete values

The active wildcard-expansion plan already notes possible integration where update mode prefers preservation when possible. A public issue would make that remaining workflow gap visible and testable.