fix(repair-built-stamp): patch the published PACKAGES.rds once bincraft drops cranlike (#236)

Follow-up to https://codefloe.com/rpkgs/bincraft/pulls/228 (bincraft#33), which drops the cranlike and desc forks.

## Why

After that change, `upload_package_index()` no longer keeps a `PACKAGES.db`.
It reuses the records of the slot's published `PACKAGES.rds`, as long as each tarball is still listed with the same ETag.
`local/repair-built-stamp.R` patched `PACKAGES.db`, so it would stop having any effect.

## Changes

- `local/repair-built-stamp.R` now patches `Built` in each slot's `PACKAGES.rds` and then re-emits the index.
  - Only the slot's own rows are patched: the generic slot's rows without a `Path`, or a per-minor slot's rows whose `Path` is its minor.
  - A missing stamp is not counted as broken, since bincraft clears it on purpose for source fallbacks.
  - With a bincraft release that still loads cranlike, the script patches `PACKAGES.db` as before, so merge order does not matter.
  - `bincraft::built_stamp()` was never exported, so the script failed at that line before this change; it now calls `bincraft:::built_stamp()`.
- The `GITHUB_PAT` comments in `reindex`, `weekly-rebuild-reindex` and `backfill-flat-safety` now give the current reason: bincraft reads DESCRIPTIONs from raw.githubusercontent.com.
- The README section on index files describes `upload_package_index()` instead of the forks.

## Testing

Tested against a moto S3 bucket, with bincraft installed from the bincraft#228 branch:

- A slot was indexed, then 3 of its 5 `Built` stamps were set to `R 4.5.0; NA; ...`.
- The dry run reported 5 entries, 3 broken.
- `--apply` rewrote the 3 stamps, and the re-emit logged `Index records: 5 reused, 0 read, 0 unreadable.`
- The published `PACKAGES` then had a valid stamp on all 5 records.
- With the released bincraft, which still loads cranlike, the script chose `PACKAGES.db`.

The stale `PACKAGES.db` objects in the slots can be deleted once a bincraft release with #228 is in use.

Reviewed-on: #236

.crow/weekly-rebuild-reindex.yaml

@@ -4,8 +4,8 @@
 # objects in place, so the slot's index still advertises the old MD5 and, for
 # anything that had been served from source, no Built stamp. Re-indexing from
 # inside a shard would mean three concurrent `upload_package_index()` calls on
-# one prefix: `cranlike::update_PACKAGES()` lists the live bucket, so an early
-# lister that uploads last publishes an index missing its siblings' work.
+# one prefix: each lists the live bucket, so an early lister that uploads last
+# publishes an index missing its siblings' work.
 #
 # So it happens exactly once per slot, here, after every shard has finished.
 # `runs_on: [success, failure]` keeps that true when a shard fails; only an
@@ -144,12 +144,11 @@ steps:
         from_secret: PGPASS
       REPO_RO_TOKEN:
         from_secret: REPO_RO_TOKEN
-      # uvr resolves bincraft's dependencies through the GitHub API, including
-      # the pat-s/cranlike@s3 fork. Unauthenticated it is rate limited, and the
-      # failure is not loud: uvr warns, falls back to the registry copy of
-      # cranlike, and the index write then dies on `unused argument (built =
-      # built)` because upstream has no such parameter. Intermittent by nature,
-      # since it depends on the rate-limit window.
+      # bincraft reads the DESCRIPTION of every new or replaced tarball from
+      # the CRAN mirror on raw.githubusercontent.com, and authenticates with
+      # this token when it is set. A slot whose published index cannot be read
+      # is re-read in full, ~25k requests, which the anonymous rate limit would
+      # cut short.
       GITHUB_PAT:
         from_secret: GITHUB_PAT
       GIT_USER: pat-s