Banked: 2026-07-14, cycle298 (Gitea v1.27.0 -> Forgejo port-lag batch, finding 298-6).
When a lagging fork DOES port an upstream security fix, it may implement the fix via a different mechanism than upstream. If the upstream fix was applied inline per-call-site and the fork consolidates it into a single shared/config location, the fork can silently miss a sibling code path the shared location doesn't reach -> a residual gap that a naive "did they port it? yes" check would WALK.
.AddConfig("http.followRedirects","false") INLINE on every git command in pull-mirror sync (fetch, prune, remote-update).ModernizePullMirrorConfig to write http.followRedirects=false to the on-disk repo git config ONCE at sync start - covers the main repo fetch/prune (they inherit on-disk config).git remote update with Dir: wikiPath (the separate <repo>.wiki.git), and ModernizePullMirrorConfig only modernizes repoPath, never wikiPath. So the wiki fetch has neither the on-disk config nor an inline override -> still follows redirects = SSRF gap.When set-differencing a fork against an upstream fix, do NOT stop at "the fork has an equivalent guard." Ask: 1. By what mechanism did the fork apply it (inline per-site vs shared/central vs config)? 2. Enumerate every call site / code path the upstream fix touched (upstream applying it N times inline is a TELL that there are N distinct paths). 3. For each path, verify the fork's mechanism actually reaches it. A central/config port that covers the common path often misses a secondary path (wiki repo, LFS repo, a per-sub-resource clone, a background job) that upstream's inline approach covered by brute force.
This is the sibling of the "centralized-fix walks / per-handler-fix yields" predictor (2026-06-13), applied to PORT COMPLETENESS instead of ORIGINAL fix completeness: a fork's centralization of a port can itself create the per-path gap.
feedback_cross_fork_portlag_primitive (memory), CONSOLIDATED-PORTLAG method.