Register: my R-1033 renumbered to R-1036 (id collision with the http row)

Another session filed R-1033 (Security & access, P2, plain http on the public
names) in 6e0643f6 while this session was working; I minted mine against the
register as it stood before that, rebased onto it without re-checking, and the
push put two R-1033 rows in OPEN-ITEMS.md — register_shape_gate red on main.

Theirs landed first and keeps the number. The apps-page-lag row (Apps & catalog,
P3) is now R-1036, with the references in the website CHANGELOG, STATUS.md and
REPORT-seo-felho-tarhely-2026-10-14.md moved with it. Register and site gates
green again. This clone's pre-push hook is unarmed (core.hooksPath unset), which
is why nothing refused the push locally; said so in the report.

STATUS.md

@@ -12,7 +12,7 @@
 - A real power cut on demo-hp: it started by itself after all 8 cuts of the night (with the BIOS set), every app back in ~4 min; stale and recovered mails true and paired.
 - A page for people searching „felhő tárhely" is live (/sajat-felho-tarhely, /en/own-cloud-storage): what cloud storage is, what to do when Google or iCloud fills up, a five-year cost table with prices read 2026-10-14, and who should NOT buy this.
 - The machine estimator is public (/gepigeny, /en/sizing), with figures from two machines (N100 and HP t740; raised only, 2026-10-14).
-- 64 apps in the catalog, the Usenet and torrent clients included (the website lists 62 of them — R-1033). OS updates, the kernel lane too, run at night.
+- 64 apps in the catalog, the Usenet and torrent clients included (the website lists 62 of them — R-1036). OS updates, the kernel lane too, run at night.
 - The hub is closed again after the 2026-10-12 security review; one box cannot read another's data.
 
 ## What is broken