Print student document button

# Print student document button

Add a Print button to the document page (`/app/documents/:id`) and the submission view (`/app/submissions/:id`) so students and teachers can print the current document or a submitted snapshot.

## Current status

`yawp-2.0` PR #105 is open and checks have been green. This is additive and still does not need a feature flag, but it needs final code review before merging because the implementation opens a print window and must avoid unsafe HTML interpolation or popup-blocker regressions.

## Problem

Students and teachers have no native way to print a document from Yawp. The workaround — using the browser's built-in print on the full app page — includes nav chrome, sidebars, and comment annotations, producing unusable output.

## Goals

- Let students and teachers print the current document in a clean, readable format.
- Support "Save as PDF" via the browser's native print dialog — no extra dependencies.
- Print the live editor state (including unsaved changes), not just the last-saved server copy.
- Strip comment/annotation markup from the printed output.

## Non-goals

- No custom PDF generation library or server-side rendering.
- No print-specific layout within the main app page (new-window approach instead).
- Comments and annotations are not printed.
- No separate print button on other surfaces beyond document and submission views.

## Domain notes

Involves the **Document** entity (`/app/documents/:id`). A Document is always editable by its owner; it may also have one or more associated **Submissions** (immutable snapshots). The print button targets the live Document state by default. If the user is viewing a submitted version (submission view), it should print that snapshot instead.

No interaction with Assignment, AssignmentType, Course, or TeacherTraining.

## UX sketch

Print button added to the document page nav bar, right side, alongside the existing Submit and DocumentHistory controls:

```
+---------------------------------------------------------------+
| [← Back]   Document title              [Print] [History] [Submit] |
+---------------------------------------------------------------+
| Editor area (full width)                                      |
|                                                               |
+---------------------------------------------------------------+
```

On click:

1. Grab live editor HTML via `editorBridgeRef.current?.getContent().html`; fall back to `data.doc.html` if the bridge is unavailable.
2. Strip comment annotation spans (`[data-comment-id]`) using `DOMParser`.
3. Open a new browser window containing a clean HTML page with:
   - A header: document title, student name, date.
   - The cleaned document body with minimal print-friendly CSS.
4. Call `window.print()` on the new window immediately on load.

The new window can be closed after printing. No loading state needed — the operation is synchronous in the browser.

Button is visible to both students and teachers.

## Data model implications

None. This is a purely client-side feature — no new fields, tables, or migrations required.

## File paths in `yawp-2.0` likely to change

- `services/web-app/app/routes/app_.documents_.$id/route.tsx` — add Print button to nav bar; implement click handler with new-window print logic.
- `services/web-app/app/routes/app_.submissions_.$id/route.tsx` — add Print button to submission view nav bar; print from the submission's immutable HTML.

No other files expected to change.

## Open questions

- [x] Should the print button also appear on the submission view (`/app/submissions/:id`)? **Yes** — decided 2026-05-02.
- [x] Should printing the live draft (including unsaved changes) be the default, or should the user be prompted to save/submit first? **Print live editor state** — no prompt required. — decided 2026-05-02.

## Edge cases

- **Unsaved changes:** The button prints the live editor state, so unsaved changes are included. This is intentional.
- **Editor bridge unavailable:** Falls back to `data.doc.html` (last server-saved state). Button should still work; user may not notice the fallback.
- **Submission view:** Print button present on `/app/submissions/:id`. Prints from the submission's immutable HTML — no editor bridge needed, no unsaved-changes concern.
- **Teacher viewing student document:** Button works the same way — teacher prints what they see.
- **Empty document:** Prints a page with just the header. No special handling needed.
- **Pop-up blockers:** Some browsers block `window.open()` if not triggered directly from a user event. The click handler must call `window.open()` synchronously (no async gap before the call).

## Test plan

- [ ] Click Print on a document with content — new window opens, print dialog appears, output contains document body without comment spans.
- [ ] Click Print on a document with unsaved changes — printed output reflects unsaved state, not last-saved state.
- [ ] Click Print on a document with comment annotations — confirm `data-comment-id` spans are stripped from printed output.
- [ ] Click Print as a teacher viewing a student document — button present and functional.
- [ ] Click Print on the submission view — new window opens with the submitted snapshot, not the live draft.
- [ ] Verify fallback: simulate editor bridge returning null — confirm `data.doc.html` is used instead.
- [ ] Test in a browser with pop-up blocking enabled — confirm the new window still opens (direct click handler, no async gap).

## Rollout

No feature flag needed — this is additive UI with no data model changes and no risk to existing behavior. Can ship as a big-bang change. Pilot schools (UA, Washington, Birmingham City) will get it on next deploy.

## Engineering handoff checklist

- [x] Domain context covered
- [x] File paths in `yawp-2.0` listed
- [x] Data model implications spelled out, including backward-compat plan
- [x] UX sketch in prose
- [x] Edge cases enumerated
- [x] Test plan written
- [x] Rollout plan decided