[Bug]: Inline document previews leave blank space and need direct revision requests #439

Summary

Inline document previews should follow the available chat width and page aspect ratio, with a wider desktop conversation and a direct right-click change request.

Problem to solve

After #438, PDF/PPT previews still use a fixed viewport height. Landscape pages leave unused space below the page, and portrait pages scroll within the preview. The default 48rem column is narrow for document work. Users must locate the footer action before selecting a change, and an agent may finish a revision without attaching its updated snapshot.

Proposed solution

Let inline pages determine height at width fit, retain page navigation and Contents in one box, and add a localized right-click Request changes action using the existing selection/request flow. Raise the default conversation maximum to 60rem while preserving explicit width preferences and responsive shrinking in split panes. Remind webchat agents to attach each completed or revised image/HTML/PDF/PPT/PPTX, including revisions saved to the same path. Preserve owned snapshots and Basic/VM delivery.

Alternatives considered

Fixed-height previews or requiring a separate expanded viewer do not satisfy the inline workflow. Reuse existing viewer, context-menu surface, attachment and normal outbox owners rather than introduce another editor.

Impact

Affected: webchat document users on Basic and VM execution. Frequency: every inline preview, especially landscape slides. Consequence: wasted chat space and missed updated deliverables.

Evidence/examples

Maintainer follow-up to merged #438, including the subsequent request for a 60rem default. Real production browser checks pass for rootless-Docker Basic and actual SSH VM execution. Native FHD split controls verify that the new maximum shrinks within pane boundaries. Focused tests and independent review accompany the implementation PR.

Implementation intent

A follow-up PR is being prepared.