fix(canvas): the edit-lock control shows locked and unlocked at a glance, without colour (v0.21.3) #335

The problem

The Controls rail's lock button looks almost the same in both states. Measured on production v0.21.2 (c5e7d8f):

• The two icons differ only in the left end of the shackle: under 1 % of the button's pixels at 4× (92 of 10,816 in light), a few pixels at the real 14 px size. Seen at actual size, both read as a closed padlock.
• The locked state's only other tell is a background change to surface-sunken: 1.07 : 1 against the unlocked background in light, 1.47 : 1 in dark, and none at all in forced colours (the system colours drop the token, and the lock is not in the rail's forced-colours pressed rule).
• The other rail toggles (Focus, Filters, Group frame, Activity) mark ON with an inset 2 px ring and a tint (5.4 : 1 in light and dark) and with Highlight / HighlightText in forced colours (15 : 1).
• The accessible name and the tooltip both name the next action ("Lock editing…" when unlocked, "Unlock editing…" when locked) while aria-pressed also flips, so the name changes with the state it is meant to report.

The control never contradicts the real state (in every measured case pressed, the closed-lock icon and the blocked edits agreed); the problem is that a locked canvas looks unlocked.

The contract (decided)

• Unlocked: an open padlock. The shackle is lifted clearly and swung outward on one side, with a visible gap above the body.
• Locked: a closed padlock, the shackle centred and fully seated in the body, plus the same pressed tell as Focus: background, inset ring and colour together.
• Never colour alone: the two silhouettes must tell the states apart in greyscale and at the real display size.
• Forced colours: the locked state uses the Highlight pair, like the other rail toggles.
• The accessible name is fixed and does not change with the state, for example "Edit lock"; aria-pressed carries the state.
• The tooltip names the next action: "Lock editing" / "Unlock editing" (with the existing explanation after it).
• Light, dark and forced colours and keyboard focus are checked automatically.
• The phone stays view-only and gets no lock button.

Before implementation

Two or three open-padlock mockups at the real size (14 px icon in the rail button, 1× and 2× device pixels), next to the closed one, in light, dark and forced colours, are compared and one is chosen. Judged at actual size, not only from enlarged crops.

Tests

• The open icon, rendered at the real 1× size: a measurable gap of background pixels between the lifted end of the shackle and the body.
• The closed icon at 1×: no such gap; the shackle meets the body on both sides.
• Each state matches its committed baseline in light, dark and forced colours, stable across runs.
• The pressed tell: the locked button's ring and background against the unlocked one meet 3 : 1 in light and dark; in forced colours the locked button is Highlight.
• Keyboard focus stays visible on a locked button (the pressed tell must not hide the focus ring).
• The name stays the same across a toggle, aria-pressed follows the state, and the tooltip names the next action, in every shipped language.

Out of scope

• Making the other rail toggles' names follow the same rule (Focus, Filters, Group frame, Activity name their state or action today): a separate memo, not this issue.
• What the lock blocks, and the lock surviving a new document: fix(canvas): a new document starts unlocked, and the edit lock blocks every user edit (v0.21.3) #334.

Released together with #334 as v0.21.3, in one pull request: #334's behaviour first, then the mockups, then this. Related: #330 starts (v0.22.0) after this release and the v0.21.4 silhouette work.