Specify perspective correction as FR-DEV-20

Issue #13 asks for a vertical and horizontal keystone, and its number was
renumbered from FR-DEV-19 when the spec gave that to mask editing. The
clause was never written into the register, so the work had nothing to
trace to.

It is written as part of framing: after the crop and the straightening,
before the stored orientation and the lens warp, carrying framing's
Compose attribute, and with the inscribed crop accounting for it.

docs/dev/requirements.md

@@ -605,6 +605,19 @@ Editing rhythm depends on the hands staying put: reaching for a menu breaks the
 edit the same way it breaks the pace of a cull. A binding nobody can discover is the same as no
 binding, which is why the generated book is part of the requirement rather than documentation of it.
 
+**FR-DEV-20 — Perspective correction.** Framing shall include perspective correction — a vertical
+and a horizontal keystone — applied before the crop. It runs in the coordinate chain after the
+crop and the straightening and before the stored orientation and the lens warp, so that "vertical"
+means vertical in the photograph as it is shown and the lens is still corrected on the full frame
+it projected. It is part of framing and carries its `Compose` attribute, so a settings paste
+withholds it by default for the same reason it withholds the crop. The correction never exposes
+undefined area on its own; where it is combined with a straightening angle, the crop that avoids
+the empty corners (`max_inscribed_crop`) accounts for it, and the crop is refitted when the gesture
+ends.
+Converging verticals are the commonest geometric fault in architectural and interior work, and
+correcting them reframes the image — which is why the order relative to the crop is not a
+preference, and why the correction belongs to composition and not to the colour operations.
+
 ### 3.4 Display and interaction
 
 **FR-DSP-1 — Proxy-resolution rendering.** The develop view renders at the resolution actually