Record the announced window, its order, and the fetch two tiles share

[iderex]

The issue this belongs to

Refs #53. This does not meet its definition of done and the reason is under
"What this does not cover".

What changed

A decision record under docs/decisions/, and its line in the index.

A client announces the artwork it expects to draw as an ordered window, and
withdraws a tile by cancelling it. The order of the window is the whole of the
priority the core accepts, and no tile carries a number beside it. 0050 already
declines a client-supplied priority on its decode admission queue and gives the
reason; a number here would be a second ordering over the same work, and the two
disagree the first time a tile announced second carries the higher number.

An announcement is advisory. A tile nobody announced is still fetched at the
moment it is asked for, so announcing is a way of being early rather than the way
of being served. That is what makes a bound on the window affordable, and what
makes cutting a window that exceeds it cost time rather than an image.

Announcements that resolve to one artwork entry under 0041 share one fetch, and
that fetch is abandoned when the last caller holding it has withdrawn rather than
when the first has.

The cap on outstanding requests the issue asks for is 0027's connection limit
rather than a number added here. What the record fixes is where the rest of an
announced window sits while those connections are busy, which is as data in
announcement order, because 0009 sizes the waiting lane once at core creation and
two hundred announced tiles cannot each hold a waiter.

0064 places the duration of the lock a caller could wait on during prefetch on
this issue. The record fixes the shape of that bound, which is that the core
calls out to nothing while holding it and the work under it is proportional to
the window, and leaves the number owed to the harness in #65.

What failure it prevents

The withdrawal rule is the one that cannot be repaired quietly. The natural
implementation abandons a shared fetch as soon as any caller withdraws, and what
that produces is one missing poster, on items that share artwork, under
scrolling. #51 has already made a missing image a first-class answer, so the
client showing the hole is behaving correctly and there is nothing for anybody to
notice. Every route by which a person would report it describes something else.

The ordering surface is the half that cannot be added afterwards. A core whose
artwork calls have no announcement has clients that call in draw order and cancel
on scroll, and an order added later is one each of them decides separately
whether to use.

Neither has happened in this tree. There is no code here for it to happen in.

Evidence

The commit these were run at:

$ git rev-parse HEAD
dde0b5f2c43e204ce4d2d327c78f12c4fedff302

What it changes:

$ git diff --name-only origin/main...HEAD
docs/decisions/0053-announced-tiles-and-the-shared-fetch.md
docs/decisions/README.md

The document check this repository runs, in full rather than as a claim that it
passed:

$ bash .github/doc-paths/doc-paths.sh check | grep -E '^ok    [0-9]+ document|^Every path'
ok    46 document(s), 50 named path(s) resolved, 0 excused as examples
Every path these documents name resolves against the tracked set.

The index carries a line per record. The first number counts the index itself,
so thirty-nine records and their index file answer thirty-nine index lines:

$ ls docs/decisions/*.md | wc -l ; grep -c '^- \[' docs/decisions/README.md
40
39

Every number inside the record is stated there as chosen rather than measured,
with #65 named as where a measured replacement comes from. That is the same
footing as the numbers in 0027, 0038, 0050 and 0054, and it is a claim rather
than a measurement because there is no code in this repository to measure.

What this does not cover

It does not meet the definition of done on #53. All three conditions there are
tests against the fake server in #21: two hundred tiles announced, a hundred and
eighty withdrawn mid-flight, the outstanding-request cap, and a duplicate
announcement causing one fetch. There is no language chosen, no build and no test
command in this tree, so none of the three can be asserted and the issue stays
open on all of them.

It decides nothing about how a requested size becomes an address or which sizes
share a cache entry. That is #49, and the coalescing rule here reads its answer
rather than anticipating it.

It does not decide whether a missing image is kept in the cache. The comment on
#51 sets out two readings of that issue's second-request condition. This record
is the narrower one, which is a second request answered without a network call
while the first is still in flight. Whether an absence is kept at all, and for
how long, reaches 0006 and 0043 and stays with #51.

It states no duration for the prefetch lock. The property is fixed and the number
is owed to #65.

Nothing here adds or edits a guard, so there is no proof that one bites.

Who has read it

Nobody but me. There is no second reader on this board tonight, and the evidence
above stands in place of one rather than the question being left open.