docs: record corrected SuperDeck architecture audit

[leoafarias]

Summary

Add the corrected architecture audit as a standalone maintainer record:

docs/maintainers/architecture-review/superdeck_architecture_adversarial_audit.md

The document distinguishes generated results, the active runtime deck, and saved decks. It records source-supported ownership defects and acceptance scenarios without prescribing a class merger or late-subscriber replay. PDF controller replacement remains a latent hazard outside the supported show() snapshot flow. Engine size and interface claims are corrected; change estimates are conditional forecasts.

Scope

Documentation only. Compared with main at d160766c862a4ea7670a41c98f085bfae33a24f7, the branch adds one Markdown file and changes no implementation, tests, dependencies, or configuration. The obsolete HTML copy and structural-check JSON were removed from the branch before this PR, and the Markdown does not cite that JSON.

Reviewed tip: d0f7bcce7fe8b472fcba201f8d99d30a6ecc23d8.

The correction range from 882a3209491f7162880718c61889d6c1d1b156d1 consists of d885cab6595a3188a4ba00e6ae35c00226a4cc82 and d0f7bcce7fe8b472fcba201f8d99d30a6ecc23d8.

Review and validation

The completed static source check accepted the corrected audit with no factual corrections required. It checked the six requested conclusions against the unchanged code baseline, callers, and existing test source. The branch tip and documentation-only comparison were rechecked before opening this PR.

No Dart or Flutter commands, application runs, or tests were executed for this documentation review. The acceptance scenarios in the audit are proposed regressions, not claims of passing runtime tests. Creating this PR does not implement those fixes or establish their behavior.

Follow-up boundary

Track implementation separately: coherent publication and saving first, memory reload completion next, and focused PDF terminal cleanup independently. Keep refresh() operation ownership as a separate correction. Shared-module placement, document identity, and optional replay must be decided from the relevant regressions rather than treated as already-proved designs.

[leoafarias]

Source-review outcome: accept the corrected audit

Reviewed d0f7bcce7fe8b472fcba201f8d99d30a6ecc23d8 against code baseline d160766c862a4ea7670a41c98f085bfae33a24f7, including the correction range from 882a3209491f7162880718c61889d6c1d1b156d1.

No factual corrections are requested. The non-documentation tree is unchanged. The final branch delta is one standalone Markdown audit; the drifting HTML and structural-check JSON are absent, and the Markdown does not cite the deleted JSON.

The corrected record separates source findings from proposed regressions and unresolved design choices. In particular, it does not treat a class merger, late-subscriber replay, or a new public PDF export-session module as a decision already proved by the source. The PDF controller-replacement callback remains a latent hazard outside the supported show() snapshot path.

Implementation follow-up, separate from this PR

Start with the publication and saving guarantees in audit section 1:

• Generate A, open saved B, return to the Wizard, then save: Markdown, artwork, and theme must describe the same deck.
• Start generation B, select saved A, then complete B: the older run must not silently replace the newer selection.
• Open valid A, then malformed B: an unsuccessful open must not leave B's document and artwork binding over A's last-good slides.
• Show a saved deck with artwork available only on disk, then fail or abandon generated-result application: fresh asset resolution and the active document must still belong to the previous deck.

Treat refresh() operation ownership as an independent correction. Follow with memory reload terminal completion, including unchanged input and no input, and focused PDF entry/terminal-cleanup tests. Choose publication identity and module placement from those regressions; do not delete the unused document revision or captured-image test hook merely to satisfy a structural preference.

This is acceptance of the documentation, not verification of implementation fixes. No Dart/Flutter commands, builds, application runs, or tests were executed for this review. Runtime acceptance scenarios remain unexecuted.