fix(poster): share one global worker pool to cap upload concurrency

[javi11]

Summary

Fixes the silent crash reported in #184 where Postie dies during bulk uploads on memory-constrained hosts (e.g. Synology NAS) once MaxConcurrentUploads is raised above 1 with PAR2 enabled. No panic, no postie_crash file → external SIGKILL from the OOM killer.

Root cause

Every Post() call previously built its own conc/pool sized to sum(provider.MaxConnections) (see poster.go:338 pre-change). On top of that, postie.Post runs PAR2 creation+post and main-file post concurrently via errgroup, so the effective concurrent Post() count is 2 × MaxConcurrentUploads. Worst case at MaxConcurrentUploads=4 with 40 connections: ~320 goroutines and ~300 MB of read-ahead body buffers in flight — enough to OOM-kill a 2-4 GB NAS.

Fix

• Single shared upload worker pool in poster. Total posting concurrency is now bounded by numOfConnections for the entire process, regardless of how many Post() calls are in flight. All concurrent Post() calls submit uploadJob entries to one channel drained by long-lived workers. NNTP connection lifecycle is unchanged — workers only hold a connection from uploadPool while actively posting an article. Worker startup is lazy via sync.Once so existing struct-literal tests keep working. Close() drains via a shutdown channel.
• Buffer pool hygiene — drop oversized read-ahead buffers (> 4× default) on return so one outlier article cannot inflate the pool's working set forever.
• Queue TOCTOU — addMu sync.Mutex serializes the check-then-Send sequence in AddFile, AddFileWithPriority, and AddFileWithOptions. goqite.Send uses its own DB handle so a SQL transaction can't span IsPathInQueue + Send; a Go mutex achieves the same atomicity. Left SetMaxOpenConns(1) alone per the explicit design note at queue.go:164.
• Runtime watchdog — 10s debug-level log of runtime.NumGoroutine() + HeapAlloc/HeapInuse/Sys in processor.Start, so the next silent OOM-kill leaves a diagnosable trend line.

Connection lifecycle

The shared pool holds long-lived goroutines, not NNTP connections. Workers acquire a connection from uploadPool only while actively posting and release it back via the existing nntppool flow. When no Post() is in flight, connections drain on the pool's normal idle schedule.

Test plan

• go test -race ./internal/poster/... ./internal/queue/... ./internal/processor/... ./internal/watcher/... ./pkg/postie/... — all green
• New TestSharedUploadPool with two subtests:
  • concurrent posts share workers and stay bounded — 8 concurrent Post() calls with MaxConnections=4; asserts peak in-flight article posts ≤ 4.
  • Close drains workers and rejects new Post calls — verifies Close() drains within 2s and subsequent Post() returns ErrPosterClosed.
• On-target validation: ask reporter (@Oleekae) to retest on the NAS with MaxConcurrentUploads=2. If it still dies, capture dmesg | grep -i killed to confirm OOM vs. in-process crash.

Fixes #184