feat: always-on TrackedMutex for lock contention instrumentation

[jfberry]

Summary

• Introduces TrackedMutex (decoder/tracked_mutex.go) wrapping sync.Mutex with TryLock-based contention detection and caller tracking
• Replaces sync.Mutex with TrackedMutex on all 9 entity structs (Pokestop, Gym, Incident, Pokemon, Station, Weather, Spawnpoint, Route, Tappable)
• Adds caller string parameter to all 31 get*Record* / Peek* functions, threaded through to Lock(caller)
• Updates ~65 call sites across 22 files with descriptive caller strings

How it works

• Fast path (~25ns): TryLock() succeeds, stores caller + timestamp — zero log overhead
• Contention path: logs [LOCK_CONTENTION] with entity type/id, waiter, holder, and hold duration, then blocks. Logs [LOCK_ACQUIRED] once acquired with wait time
• Long hold: logs [LOCK_HELD_LONG] on Unlock if held >5s

Example output

WARN [LOCK_CONTENTION] Pokestop id=abc123 waiter=saveIncidentRecord holder=clearPokestopWithLock held_for=2.3s
WARN [LOCK_ACQUIRED] Pokestop id=abc123 caller=saveIncidentRecord waited=4.1s (holder was clearPokestopWithLock)

Test plan

• go build ./... compiles cleanly
• go vet ./... passes
• go test ./... all tests pass
• Deploy to staging and observe logs under load — verify [LOCK_CONTENTION] appears only during actual contention, silence otherwise

🤖 Generated with Claude Code