Overlapping writes to a site's metadata can drop a ticket branch's patch base #172

Every write to a site's stored metadata reads the whole record, changes one field and writes it back. Two writes that overlap therefore lose one of the two changes — the second one read before the first one wrote, so it saves a record that never had the first change in it.

This pattern predates ticket branches and has been harmless so far, because the fields it holds are ones a person changes one at a time: a label, a flag, a date. Losing one is a cosmetic bug that the next write fixes.

What changed with #108 is what is now stored this way. A branch records the trunk commit it was born at, and that value is the base every patch for that ticket is generated against. It is written once, when the branch is created, and read for the rest of the branch's life. If it is lost, the patch is silently generated against the wrong base — not empty, not an error, just wrong in a way that shows up when someone tries to apply it.

The overlap is not hypothetical: creating a ticket while a trunk update is finishing writes to the same record from two places.

Worth deciding whether the fix is serialising writes to this record, making the write take the field rather than the record, or something narrower for the one value that cannot be lost. The general fix is more code than the specific one, but the specific one leaves the pattern in place for whatever gets stored next.

Narrow, pre-existing, and the value at stake is the one thing the branch cannot recompute.