QueryStoreCollector.BuildPayloadBody doc comment says 53 reader ordinals; the real number is 55 #1871

Found during the #1848 live Azure SQL Database validation. Not a product defect - the code is correct
and the shipped behavior is right. This is a stale number in a doc comment that has already propagated
into two issue write-ups, so it is worth correcting before it misleads someone auditing the reader
contract.

QueryStoreCollector.BuildPayloadBody's XML doc says:

Both forms therefore select the identical 53 reader ordinals in the identical order

The actual number is 55. Verified three ways:

1. Live Azure SQL Database, splitting the result header on the column separator: 55.
2. ReadRowsAsync references ordinals 0..54 - IntervalStartTimeUtc = reader.IsDBNull(54) ? null : reader.GetDateTime(54) is the highest.
3. The class-level doc on QueryStoreCollector already states it correctly: "55 selected columns; the
   stored row is 56 - database_name is supplied client-side".

So the class doc and the reader agree on 55; only BuildPayloadBody's own summary says 53. The count
likely predates the #1841 tier-2 interval-identity pair (runtime_stats_interval_id and
interval_start_time_utc), which added exactly the 2 columns that make up the difference.

The stale number was carried into #1844's report and from there into #1848's Edge B wording ("Confirm
the 53-column result set binds on a real Azure database"). The binding itself was confirmed on live
Azure - 55 of 55 columns bound on both the Lite shape and the Darling (CapturePlanXml = true) shape.

Fix: change 53 to 55 in the BuildPayloadBody XML doc comment. One word. Worth doing because
this specific comment is the drift guard for the two execution paths' column sets - a wrong count in the
one place that exists to keep those paths honest is the comment most likely to be trusted during a
future audit.

🤖 Generated with Claude Code