Lorebase 0.4.0

Added

• Open merge Conflicts say who changed each side and when (operations, tour): an Attribute Conflict (DV1, DV3) carries provenance with, for ours and theirs, the provenance_id, the time at, the actor, the origin type, the source of a sync, the principal of an Operation and the origin labels of the last change of that Attribute, when the merge has a Lineage loader (Keeper always wires one). It is null on the other Conflict kinds and for a side of unknown Lineage, it is withheld with the values from a reader without clearance for a sensitive Attribute (and when it names something the reader's schema leaves out), and it is not part of the fingerprint. GET .../proposals/{p}/conflicts, the OpenAPI document (ConflictOut.provenance), the Python client (ConflictItem.provenance) and the Review resolver of the web app, which shows it under the Ours and Theirs headers, carry it
• Readers can see that a Conflict is pending (MCP): while a Proposal is stuck on a Conflict the target branch keeps the value merged before, and GET .../kinds/{kind}/records/{key}?conflicts=true now adds conflict_in_progress, a list of {proposal_id, conflict_id, code, attribute, competing_hash} for the open Conflicts about the Record in open Proposals into the branch read (empty when none; branch heads only). It is opt-in: without the parameter the member is null and the read, its cache entry and its ETag are as before; with it the pending Conflicts are looked up on every request (one probe of a new partial index) and are part of the ETag, since they change without a new Revision. Herald's lorebase_get asks for it by default and ends its output with a conflict_in_progress: line per contested Attribute (herald.output.pending_conflicts, default true); the Python client takes records.get(..., conflicts=True). An entry is left out, not masked, when the reader may not read the Proposal (its source branch) or the contested Attribute (hidden by projection or masked by sensitivity), so the marker never reveals a Proposal, an Attribute name or a hash they could not see elsewhere. Listings, queries, search and neighborhoods do not carry the marker

Changed

• Herald's lorebase_get now asks for the pending-Conflict marker by default and ends its output with a conflict_in_progress: line per contested Attribute; set herald.output.pending_conflicts to false to restore the previous output.
• The result of a fast-forward merge now carries the target head as its parent, so history stays connected.

Upgrade notes

• Migration 0048 (additive) creates the partial index ix_conflicts_open_element on the unresolved rows of conflicts; the migrate step applies it.
• RecordResponse gains an optional conflict_in_progress member. It is opt-in (?conflicts=true); without the parameter it is null and the read is unchanged.
• Herald lorebase_get asks for it by default (herald.output.pending_conflicts, default true).
• Conflict gains an optional provenance member (null on the Conflict kinds that have no sides).
• Fast-forward merge results carry the target head as parent.
• The ranges between workspace packages move to >=0.4,<0.5; install matching versions of the Lorebase packages together.