[internal review, not for upstream yet] proposal-0052: name the additive property of anchored

[ColinDKelley]

Internal-review draft

This is the second of two upstream-bound PRs that follow up on prometheus/prometheus#18679. The companion docs callout is at Invoca/prometheus#25.

Base is Invoca/proposals:main, which was just forked from prometheus/proposals@0c03113 and has zero drift. Do not push upstream until we've reviewed.

What this changes

proposals/0052-extended-range-selectors-semantics.md, inside the ### How This Proposal Works → #### anchored block: adds a new "Composability as the additive property" sub-section immediately after the existing "Use cases" bullets. The sub-section:

1. Names the property that the proposal's "Improved composability across range boundaries" bullet was already pointing at.
2. States it in PromQL with the same three-timestamp formulation we're proposing for the user-facing docs and the feature_flags.md callout.
3. Explains why the equality is exact (left-open/right-closed plus the dual role of the anchor sample) rather than merely "improved."
4. Connects the existing partial-dataset diagram (line 235) to the property — that diagram is composability in action and now we say so.
5. Links to #18679 for the precise statement and the proposed invariant tests.

Rendered preview: proposals/0052-extended-range-selectors-semantics.md on this branch

Why amend the proposal (not just the docs)?

• The proposal is the long-lived spec. If anchored is going to be the standard answer for "give me drop-in increase/rate that I can trust under irregular scrapes," the spec should name that guarantee — the same way the existing pitfalls section in the proposal names what was wrong with the legacy rate.
• Citing the partial-dataset diagram inside the proposal grounds the property in the proposal's own evidence, not just an external issue.
• The proposal author (@roidelapluie) explicitly listed Invoca's y-rate design as prior art, so giving the property a name and putting it in the proposal is a natural follow-through.

Review checklist

• Sub-section fits between the existing "Use cases" list and the "Anchored increase and complete dataset" image
• Phrasing of "dual role, not double-membership" reads cleanly to a fresh reader
• Link to #18679 anchors at the right place (the property statement, not just the issue index)
• No accidental edits to other proposal sections
• Tone matches the surrounding proposal text (declarative, design-doc voice)

Once approved

• Retarget base to prometheus/proposals:main
• Convert from draft to ready-for-review
• Cross-link from upstream issue #18679 and from the feature-flags PR