main.go is a merge hotspot: split http-honeypot CVE classifiers into one file per CVE

[Xore]

Problem

arcane/home/honeypot-http/http-honeypot/main.go is a structural merge hotspot. Every new
CVE classifier adds to two shared regions, so any two CVE branches in flight collide in both
places simultaneously.

The two regions:

1. One flat switch in classifyPayload, ordered most-specific-first. New CVE cases must
   be inserted above the generic serialized-object case or they are swallowed by it.
   The ordering is semantic, not cosmetic — a rebase that "cleanly" merges the wrong side of
   the ordering silently breaks detection.
2. One shared helper block below the switch, where all classifier helper functions live.

Evidence

Three separate PRs have now hit the same collision in the same file:

PR	Issue	Conflict
#3423 → replaced by #3444	#3189 TeamCity	main.go classifier switch + helper block
#3425 → replaced by #3449	#3309 WordPress	main.go classifier switch + helper block
#3442	#3394 Ollure	main.go classifier switch (vs #3447 scanner-laundering)

In every case the resolution was a manual semantic union that had to be re-derived by hand,
and in the first two the resolution was complex enough that a clean replacement PR was opened
instead of rebasing.

Two of those three resolutions also had to adjudicate a genuine semantic question that no
merge tool can answer — most recently, url.ParseQuery in main's wordpressPagenameTraversal
silently drops any pair containing ;, which would have destroyed an intact
data://text/plain;base64,... value the new classifier depended on. That is the kind of bug
that survives a successful rebase and is not caught by tests.

Impact

• Every concurrent CVE PR pays a hand-merge cost proportional to how many CVE PRs are open.
• Ordering errors in the switch are silent — tests may pass while detection is broken.
• The failure mode is a red CI or a merge conflict, neither of which surfaces the real risk:
  a correct-looking merge with wrong classifier precedence.

Proposal

Split the classifiers out of main.go into one file per CVE under the same package:

classify_teamcity.go
classify_wordpress.go
classify_ollure.go
...

with a small dispatcher in main.go. Go's package-level symbol resolution means the
per-CVE files stay independent, so concurrent CVE branches touch only:

• their own new file, and
• the one-line registration in the dispatcher.

That reduces a whole-file conflict to a two-line adjacent-hunk conflict, and makes the
most-specific-first ordering explicit at a single, reviewable site instead of spread across a
700-line switch.

Notes

• The dispatcher introduces one indirection, so per-payload cost is one extra function call
  on a path that already does string matching. Negligible for a honeypot, but worth stating
  rather than assuming.
• A per-CVE file makes the "no AI attribution" and per-CVE test placement obvious as a side
  effect.
• This is a refactor, not a behaviour change: every case and its ordering must be preserved
  exactly, and the existing tests should prove it without modification.

[Xore]

Closing as completed -- the work landed.

refactor(http-honeypot): one file per CVE, and pin the classifier order (#3464) (#3470) (merged 2026-09-28)

Verified on main: 8 classify_*.go files under arcane/home/honeypot-http/http-honeypot/, including the classifier-order test that pins dispatch order.

The refactor was done with the semantics preserved, not merged blind: the agent proved payload -> label identical before and after over the same corpus, and added a coverage test that fails loudly when a dispatch class has no corpus row -- the exact staleness this issue existed to prevent.