@@ -74,6 +74,18 @@ ignore:
 # `"flags": []`) and no status reads -- where a flag the suites did fill would answer with their coverage.
 # One report per commit needs no flag to tell the suites apart.
 #
+# Measured *after* this file landed on `master` (merge `b4b9a70d`, 2026-10-13), so that an earlier, inferred
+# reading is corrected here instead of repeated: the registry entry outlives the declaration. The commit's own
+# upload was processed against this tree -- `/commits/b4b9a70dfd6bb453ff7bcd03a00294be38c0d362/uploads/`
+# answers `count: 1`, `"flags": []`, 537 files / 58 907 lines at 04:04:43Z -- and nine minutes later `/flags/`
+# still answers `{"count": 1, "results": [{"flag_name": "unittests", "coverage": 0.0}]}`, with
+# `/flags/unittests/` live (HTTP 200, carrying a `coverage` link). So that list is driven neither by the
+# current contents of this file nor by the head upload's flags: it is a repository-level registry Codecov
+# keeps, and no directive in this file deletes an entry from it (deleting a flag is a dashboard action).
+# BLOCKED (2026-10-13, outside this repository): the lingering `unittests` registry entry itself -- the same
+# class of item as `codecov/project` below, and equally free to leave alone, because no upload carries that
+# flag and no status reads it.
+#
 # Known and deliberately not "fixed" here: `codecov/project` has never been posted in this repository.
 # Checked through the GitHub API for the promotion commit `58f297e` (when the current CI first ran, where
 # `codecov/patch` still arrived as a legacy commit status), for `204d9f8`, `4283626` and `b6bcf34`, and for
 
@@ -43,7 +43,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **`master` is now the `net11.0` / C# 15 line; the `net10.0` / C# 14 line is parked on `release/v2.0`.** The 2026-10-10 owner decision (superseding the 2026-09-25 one in `docs/performance/BEAT_SQLITE_ALL_AXES_PLAN.md` §9 row 9) promotes the v2.1 RC line to the main branch at **2.1.0**. .NET 11 GA is 2026-11-10, so until then the SDK pin stays `11.0.100-rc.1.26425.128` with `allowPrerelease`, and that is the one reason an RC pin appears on `master`. Prepared on `promote/net11-main-20261010` as a six-commit series: a convergence merge of `origin/master` (dependency bumps, install-doc fixes, and the Dockerfile `ARG VERSION=2.0.0.3` bump the net11 line had lost — verified `build` 0 errors and core suite **1995 / 0 failed / 0 skipped in 80,3 s**), the CI restructure, the net11 Dockerfile, the docs, and an isolated release-metadata commit.
 - **The CI pipelines are split by line instead of by SDK.** `.github/workflows/ci.yml` (what `master` triggers) becomes the net11.0 pipeline: the .NET 11 SDK pin with `include-prerelease`, the four test hosts under `bin/Release/net11.0`, and the `coverage` job plus the core-only dispatch `publish-core` job carried over from the deleted `ci-net11.yml`, so no capability is lost. `.github/workflows/ci-net10.yml` is the old master pipeline retargeted to `release/v2.0` (tags `v2.0*`, pack/publish gated on that branch). `compatibility-smoke.yml` and `dependency-submission.yml` move to the same pin, because the server and the solution they exercise are net11 now.
 - **The server image is net11-aware again, closing the open item in the 2.1.0-RC.3 release notes.** The Dockerfile moves to `sdk:11.0` / `aspnet:11.0` and `docker-publish.yml` drops the `!v2.1*` exclusion (excluding `v2.0.x` instead, which belongs to the parked line). The container deliberately does **not** copy `global.json`: it builds with the image's own SDK, so the repository's RC pin cannot fail an image build on a missing SDK. Full record, the flip procedure and the GA checklist: `docs/net11/PROMOTION_TO_MAIN.md`.
-- **`codecov.yml` no longer declares a flag that nothing uploads, and its PR comment no longer advertises two sections that can never render.** The `unittests` flag (`paths: [src/]`, `carryforward: true`) was the repository's only entry in Codecov's flag list with **no coverage at all** — `/flags/` answers `{"count": 1, "results": [{"flag_name": "unittests", "coverage": 0.0}]}` — and it could never be anything else: the `coverage` job hands all three Cobertura reports to a *single* `codecov/codecov-action` call and deliberately uploads **unflagged** (a status that names no flag would have no data to read), which Codecov records as one upload for the commit — confirmed against the API for `4283626d8235b4e2175097a929a9b0e1613a17b2` (the endpoint wants the full 40-character SHA), whose `uploads/` endpoint answers `count: 1` with `"flags": []`. The file's own header comment asserted the opposite ("we expect exactly 3 uploads"), which is what made the mismatch look like a missing upload; it now states the measured shape, and `after_n_builds` stays unset for that reason (waiting for three uploads would leave every commit without a comment or a status). `flags` and `components` are dropped from `comment.layout` (`header, diff, tree`) because this file defines no `component_management` either. No status reads a flag, so pass/fail behaviour is unchanged; validated with `codecov.io/validate` (*Valid!*).
+- **`codecov.yml` no longer declares a flag that nothing uploads, and its PR comment no longer advertises two sections that can never render.** The `unittests` flag (`paths: [src/]`, `carryforward: true`) was the repository's only entry in Codecov's flag list with **no coverage at all** — `/flags/` answers `{"count": 1, "results": [{"flag_name": "unittests", "coverage": 0.0}]}` — and it could never be anything else: the `coverage` job hands all three Cobertura reports to a *single* `codecov/codecov-action` call and deliberately uploads **unflagged** (a status that names no flag would have no data to read), which Codecov records as one upload for the commit — confirmed against the API for `4283626d8235b4e2175097a929a9b0e1613a17b2` (the endpoint wants the full 40-character SHA), whose `uploads/` endpoint answers `count: 1` with `"flags": []`. The file's own header comment asserted the opposite ("we expect exactly 3 uploads"), which is what made the mismatch look like a missing upload; it now states the measured shape, and `after_n_builds` stays unset for that reason (waiting for three uploads would leave every commit without a comment or a status). `flags` and `components` are dropped from `comment.layout` (`header, diff, tree`) because this file defines no `component_management` either. No status reads a flag, so pass/fail behaviour is unchanged; validated with `codecov.io/validate` (*Valid!*). The flag **registry entry** Codecov holds for the repository is *not* removed by deleting the declaration — measured after this landed on `master` (merge `b4b9a70d`, 2026-10-13, with the merge commit's flag-free upload processed at 04:04:43Z): `/flags/` still answers `{"count": 1, "results": [{"flag_name": "unittests", "coverage": 0.0}]}` and `/flags/unittests/` is still live. That entry costs nothing (no upload carries the flag, no status reads it) and removing it is a Codecov dashboard action, recorded as `BLOCKED` in `codecov.yml` rather than left as an inference.
 
 
 ### Fixed
 
@@ -5213,3 +5213,18 @@ Nothing in the repository explains a stall: no `.git/*.lock`, no fsmonitor daemo
 - Commit: `4eafadd8` (`chore(codecov): …`) on `perf/autonomous-20261012`, pushed, PR #460 opened against `master` and left green for the owner — merging publishes to NuGet.org, so landing stays an owner action.
 - NEXT: unchanged queue head — session 81's `NEXT:` §5.1 INSERT item (i), the identity-remap fast path for `InsertBatch(table, rows, columns)` when the column order already matches the table order (112 B/row on the array arm). Open and BLOCKED, carried forward rather than dropped: `codecov/project` is never posted for this repository (evidence above, restated in `codecov.yml`), needs a Codecov dashboard/app check, and costs nothing while absent.
 
+
+
+### 2026-10-13 (session 86 — addendum 2) — owner instruction lands PR #460 on `master`, and the post-merge flag-list prediction is measured refuted
+
+- Session: 86 (same session, addendum 2 — the merge the owner instructed, plus the post-merge observation addendum 1 promoted to a claim, which the measurement then contradicts).
+- Command(s): `gh repo view --json defaultBranchRef`, `git ls-remote --heads origin main master`, `gh pr view 460 --json state,mergeable,mergeStateStatus,headRefOid`, `gh pr checks 460`, `gh pr merge 460 --merge`, `git fetch origin` / `git --no-pager log origin/master`, `gh api repos/.../actions/runs?head_sha=b4b9a70d…`, `gh api repos/.../actions/runs/<id>/jobs`, `curl .../commits/b4b9a70d…/uploads/`, `curl .../flags/`, `curl .../flags/unittests/`.
+- Verdict: **LANDED on `master` as `b4b9a70d` (merge commit, 2026-10-13T04:01:14Z, owner instruction), master green in every job including `Publish to NuGet.org` — and the flag-list prediction of addendum 1 is REFUTED by measurement, so it is corrected in `codecov.yml`, `docs/CHANGELOG.md` and here rather than left standing.**
+- The merge: PR #460 was `OPEN` / `MERGEABLE` / `CLEAN` at head `f2cc566d` with no failing or pending check, so it went in as a merge commit, matching the repository's own history (`Merge pull request #448 …`). `origin/master` is now `b4b9a70d` with all three commits (`4eafadd8`, `0e59d9df`, `f2cc566d`) on top of `b6bcf34a`; the feature branch was left in place, since deleting it was not asked for. "Push to main" means `master` here: `gh repo view --json defaultBranchRef` answers `master` and `git ls-remote --heads origin main master` returns `refs/heads/master` only — there is no `main` branch to push to.
+- Master's pipeline on `b4b9a70d` (`CI/CD Pipeline` run `38344447898`): `Build and Test` success on windows-latest, ubuntu-latest and macos-latest, `Coverage (net11.0)` success, `Pack NuGet Packages` success, **`Publish to NuGet.org` success** — the publish a green master push triggers (session 85 addendum 1's reading), which is why landing the PR was an owner action. `Pack + Publish core to NuGet.org (manual)` skipped, its `workflow_dispatch`-only condition. `.github/workflows/ci.yml` lines 361 and 455 pass `--skip-duplicate`, so a later docs-only push cannot turn master red on an already-published version.
+- **Refuted, with the evidence that refutes it — addendum 1 predicted the flag "disappears from `[`/flags/`]` when `master` carries this change". It does not.** The merge commit's own coverage upload was processed at **04:04:43Z**, by a tree that contains no `flags:` section at all: `/commits/b4b9a70dfd6bb453ff7bcd03a00294be38c0d362/uploads/` answers `count: 1`, `state: merged`, `"flags": []`, 537 files / 58 907 lines. Nine minutes later, at 04:13:47Z, `/flags/` still answers `{"count": 1, "results": [{"flag_name": "unittests", "coverage": 0.0}]}`, and `/flags/unittests/` answers `HTTP 200` with a `coverage` link — a live registry entity rather than a 404. The list is therefore driven neither by the current contents of `codecov.yml` nor by the head upload's flags: it is a repository-level **registry** Codecov keeps, and no directive in the file deletes an entry from it.
+- BLOCKED (2026-10-13, outside this repository), recorded in `codecov.yml` and carried in this entry's `NEXT:` line, never dropped: the lingering `unittests` registry entry itself. Deleting it is a Codecov dashboard action — the same class of item as `codecov/project`. It costs nothing while it stands: `coverage: 0.0` on a flag no upload carries and no status reads, with `codecov/patch`, the PR comment and the in-job 18 % floor (`tools/measure-coverage.ps1 -Floor 0.18`) all still reporting.
+- Why the correction is a file change and not a note: addendum 1 turned one observation (the list unchanged while the PR was open) into a *prediction*, and the first post-merge measurement contradicts it. `codecov.yml` now carries the measurement — merge SHA, upload timestamp, both endpoint answers — so the next session can re-check rather than re-infer.
+- Commit: this addendum plus the `codecov.yml` and `docs/CHANGELOG.md` corrections, on `perf/autonomous-20261013`, pushed as a pull request against `master` and left for the owner — a merge there republishes packages (`--skip-duplicate`), so landing stays an owner action.
+- NEXT: unchanged queue head — session 81's `NEXT:` §5.1 INSERT item (i), the identity-remap fast path for `InsertBatch(table, rows, columns)` when the column order already matches the table order (112 B/row on the array arm). Open and BLOCKED, carried forward rather than dropped: `codecov/project` is never posted for this repository, and the `unittests` registry entry survives the declaration that created it — both need Codecov dashboard/app actions and neither can be done from this repository.
+