feat: make locked fields unlockable via the lock icon (#12330)

[oaksprout]

You set the work. #12330: "make the lock icon toggleable: a click unlocks the field, allowing to change name, operator, etc." — your own proposed design.

It's done. The lock icon is now a real button; clicking it unlocks the field for the rest of the editing session. Fixed at the one place all locked-field types converge, so it covers name, brand, network, operator, and flag in one change. Five regression tests written before the fix, including the actual case this issue is about: staying unlocked across a later re-render.

Here's the evidence.

• Fresh clone at 87376a46 (develop), patch applied, npm run build (this repo generates its locale/data files), then the network was disconnected.
• Full suite in a clean node:22-bookworm container: 2,368 pass, 0 fail (16 skipped / 6 todo — matching base) across 138 files.
• eslint and tsc clean.

Audit trail — an independently checkable record that these checks ran, in this order, before this PR existed

Base commit	87376a46b56edecdfce8e44c01731c9403de7b51 (develop)
Container	node:22-bookworm@sha256:5647be70… (linux/arm64), network off during tests
The patch, content-addressed	record
The verification result, signed by a second key	record
Timestamped sequence	work assigned → work delivered → checks passed

What this proves: the checks ran, in that order, on exactly this patch, before this PR was opened — none of it can be backdated or swapped afterwards. What it doesn't prove: that the change is right. The two signing keys are distinct but run by the same project, and the record lives on a test network. Correctness is your judgement, which is the point.

Written by an AI agent; reviewed and sent by a human who answers the review. We're testing whether work checked this way is useful to maintainers — blunt feedback welcome, including "don't".

---

Everything below is written by Claude

Closes #12330.

The lock icon becomes a real <button class="lock-icon"> (matching the existing remove-icon/modified-icon button pattern in modules/ui/field.js — inherently keyboard-actionable, same hover behaviour). Clicking it sets a _lockOverridden flag that clips the per-keystroke calcLocked() recomputation; the icon disappears and the field behaves like any normal field. Re-render reuses the existing field.render() path — no new machinery. The lock tooltip is reworded (data/core.yaml) to explain the new interaction, per your aside about why wikidata blocks the edit.

Notes for the reviewer

• Unlock is one-directional, not a bistate toggle — your comment specifies "a click unlocks"; re-locking would need design decisions (interaction with per-keystroke recomputation) the issue doesn't cover. Happy to extend if you want a true toggle.
• No distinct "unlocked" glyph — the icon simply disappears once unlocked. An open-padlock state is a small buildable change (faIcons set in scripts/build_data.js) if preferred.
• The tooltip rewording is a judgement call — different copy welcome.

[matkoniecz]

Commented on parent issue in. #12330 (comment)

[matkoniecz]

wtf is with this references above?

[oaksprout]

That's my doing — I linked this PR as an example in comments on other projects, and GitHub shows every mention as a reference here. Nothing was posted to this PR itself. Sorry for the noise.

[matkoniecz]

Can you attach video of that feature in action to demonstrate it works?

[oaksprout]

I don't think my local setup would handle running a build of iD to record that unfortunately, so I can't get you a video. Happy to describe the behaviour in more detail or walk through it with screenshots instead if that's useful, let me know.

[matkoniecz]

you can also use CI build available via

github-actions Bot deployed to pr-preview-12631 5 days ago