docs(config): app-id resolution update (Linear Code named; five still open) (#881)

Small follow-up to #878. That PR recorded 262318 and 1658531 as
unnameable; public app metadata (`GET /apps/{slug}` returns the app
`id`) resolves **1658531 = Linear Code**, which holds `always` bypass on
all 43 `EstateBranching` applications — an app with standing push rights
over every default branch in the org, sitting outside the §7.3 keep
list. It also lets the keep-list ids be *confirmed* rather than trusted:
46505 gitguardian, 347564 coderabbitai, 1236702 claude, 2538504 oikosbot
all match.

Five ids stay open — 1561, 85455, 262318, 946600, 3953924 — with their
measured bypass modes now written into the row, including the detail
that 1561 and 3953924 hold `always` on `deed-ecosystem`'s *tag* ruleset
(tag rewriting). Installations endpoints are 403/404 for this token, so
naming them is a Settings → Applications lookup.

Docs only; no ruleset was touched (writes are 404 for this token, and
the remediation bodies in `estate-audit/ruleset-repair/` remove grants,
not apps).

Author: hyperpolymath

config/README.adoc

@@ -203,11 +203,22 @@ REST API.
   re-read of live state so a concurrent owner edit is skipped rather than overwritten.
   `anvomidaviser/Optimus-Branch` (14968878) is *disabled*, so it fails that planner's
   active-only precondition: delete it outright rather than repairing it.
-  *Still unresolved by design:* 1561 / 85455 / 946600 (`/user/installations` → 403, marketplace
-  index → 404, no `GET /apps/{slug}` candidate reproduces them), plus two ids this scan is new
-  to — 262318 and 1658531 — which hold `always` bypass on `EstateBranching`. Unidentified
-  standing push rights on every default branch in the org; resolve in Settings → Applications
-  before assuming they are wanted. O5 stays open for all five.
+  *App-id resolution, as far as a read-only token can go:* `GET /apps/{slug}` is public and
+  returns the app's `id`, so candidate slugs can be confirmed rather than guessed. That
+  independently verifies this row's keep-list ids — gitguardian 46505, coderabbitai 347564,
+  claude 1236702, oikosbot 2538504, and via check-run metadata also dependabot 29110,
+  github-actions 15368, sonarqubecloud 12526 — and it names *1658531 = Linear Code*
+  (`always` on all 43 `EstateBranching` applications). Method: 102 candidate slugs plus the bot
+  logins harvested from issue comments and commit authors across 30 repos; results in
+  `estate-audit/data/app_id_resolution.json`.
+  *Still unnamed, and they are the ones that matter:* 1561 (`always` on 9 active rulesets),
+  85455 (`pull_request` on 8, `exempt` on 1), 262318 (`always` on 44 — i.e. `EstateBranching`
+  plus one), 946600 (`always` on 53, `pull_request` on 3), 3953924 (`always` on 1). Two of
+  those, 1561 and 3953924, sit on the tag ruleset of `deed-ecosystem` with `always`: tag
+  rewriting is in scope for an app nobody can name. `/user/installations` and
+  `/orgs/*/installations` are 403/404 for this token and the marketplace index is 404, so
+  naming them needs Settings → Applications. O5 stays open for all five; none is on the keep
+  list, which is why the remediation plan removes the grant rather than the app.
   *Keep-list note, still valid:* on active *repo* rulesets the only integration bypasses are
   oikosbot (6) and claude (2), so installing CodeRabbit also means adding `coderabbitai`
   (347564) to the estate ruleset or its auto-fix pushes cannot reach a protected branch.