Request-first lure pokemon processing

[jfberry]

Fixes #390. Closes #283.

Problem

A failed pokestop lookup while processing a lure MapPokemonProto committed a partially initialized pokemon record: indexed in the R-tree at (0,0), no pokestop_id, no expiry, marked non-new — and therefore permanently unrepairable, while a later DiskEncounter would happily attach IVs and fire hundo webhooks at lat/lon 0 with disappear_time 0 (#390). Structurally, the whole diskEncounterCache existed only because the DiskEncounter response carries no location, forcing responses to wait for a GMO (#283).

Approach

Each proto contributes what it alone knows, in any arrival order:

Source	Contributes
GMO fort entry (fort.ActivePokemon)	placement (fort id + coords, captured at extraction) and the verified despawn time
DiskEncounterProto (request)	placement for encounter-first arrivals (encounter id, fort id, fort coords)
DiskEncounterOutProto (response)	species, IVs, CP, level

• No lure path touches the pokestop record anymore. The lure pokemon rides inside its fort's own GMO entry, so RawMapPokemonData now carries the fort's id/lat/lon captured at extraction — placement cannot fail, even in pokemon-only scan contexts where the fort cache is never populated.
• decodeDiskEncounter now requires and parses the request proto (same posture as GetStationDetails): encounter id comes from request.EncounterId (the PokemonDisplay.DisplayId stand-in is gone), and an encounter with no prior GMO creates a fully placed lure_encounter record with a 180 s unverified expiry (lure spawns live 3 minutes). A later GMO tightens it to the verified despawn. Requests missing the payload are counted (request_missing) and skipped.
• updateFromMap is now an order-tolerant merge: new records get placed from the captured fort fields; existing lure records only receive GMO-owned facts (verified expiry, cell id, username backfill) — never a seen-type downgrade, never touching encounter data, and no-change sightings skip the save.
• diskEncounterCache is deleted — nothing waits for anything.

Testing

• Regression tests mirror the Lure Pokemon becomes unqueryable after Pokestop lookup failure #390 repro end-to-end: unknown-fort GMO placement, encounter-first creation (webhook carries real coords and a future expiry), GMO-after-encounter merge, GMO-first upgrade, request-missing skip, and v2/v3 scan visibility of estimated-expiry records.
• go build, go vet, full go test ./..., and golangci-lint run are clean; the new tests pass under -race.
• Note: a pre-existing (on main) test race in decoder/station_battle_test.go (direct statsCollector reassignment vs the async stats worker) was found while verifying — left for a follow-up since it's unrelated to this branch.

🤖 Generated with Claude Code

[Mygod]

Thanks — this looks like it fixes #390 and substantially improves the request-first DiskEncounter path. However, I found a separate live-wire issue that this PR does not currently cover.

I captured and decoded current GET_MAP_OBJECTS traffic:

• 17,009 GMO payloads
• 67 unique lure Pokémon in fort.ActiveFortPokemon
• zero occurrences of singular fort.ActivePokemon
• 65 of those lure IDs later received a successful DiskEncounter
• none appeared through Nearby, Wild, Catchable, Tappable, or normal Encounter paths

At aebc868, decodeGMO still extracts only singular fort.ActivePokemon:

Golbat/decode.go

Lines 553 to 561 in aebc868

	if fort.ActivePokemon != nil {
	newMapPokemon = append(newMapPokemon, decoder.RawMapPokemonData{
	Cell: mapCell.S2CellId,
	Data: fort.ActivePokemon,
	Timestamp: mapCell.AsOfTimeMs,
	FortId: fort.FortId,
	Lat: fort.Latitude,
	Lon: fort.Longitude,
	})

Consequently, PR #391 should make Disk-encountered lure Pokémon visible using the request coordinates, but:

• lure Pokémon without a DiskEncounter remain absent;
• repeated-only GMOs cannot provide the verified ExpirationTimeMs;
• the new GMO placement/merge logic is never reached for the current wire format.

There being only one active lure Pokémon per stop is compatible with this: the repeated field simply contains one LURE wrapper while the singular field remains nil.

I think the repeated-field ingestion should be tracked separately from #390. The eventual fix should retain singular support, iterate ActiveFortPokemon, unwrap non-nil PokemonProto entries, filter SpawnType_LURE, and deduplicate by encounter ID if both representations appear.

A decodeGMO regression test with ActivePokemon == nil and one repeated ActiveFortPokemon entry would catch this. The current tests construct RawMapPokemonData directly and therefore bypass the missing extraction step.

[jfberry]

Confirmed and fixed in 23a2334 — thanks for the capture work, and to the fixture for making this trivially testable.

Root cause matched your analysis exactly: extraction only read the singular fort.ActivePokemon, which is nil on current wire traffic; lure pokemon arrive as repeated fort.ActiveFortPokemon wrappers (SpawnType == LURE, nested MapPokemonProto). Notably the nested proto's lat/lon are zero on the wire, so the enclosing fort's coordinates are the only usable ones — the capture-at-extraction design this PR introduced already supplies them, so the fix stayed contained to the extraction layer.

What landed:

• extractFortMapPokemon unwraps LURE entries from the repeated field, retains legacy singular support, dedupes by encounter ID when both representations appear, and filters POWER_UP wrappers (nil wrapper/nil inner proto safe).
• Extraction-layer regression tests driven by a sanitized live-capture fixture (testdata/gmo-active-fort-pokemon.pb) with ActivePokemon == nil and one repeated LURE entry — addressing the gap you pointed out where the existing tests constructed RawMapPokemonData directly.

Folded into this PR rather than tracked separately since without it the PR's GMO merge path is dead code on current traffic.