Address seed-packet review: 413 mapping, deadline, rollback, dedup

Gadfly findings on #94, the real ones:

- scanSeedPacket extends only the READ deadline; a slow upload + a live
  vision call runs past the server's absolute 30s WriteTimeout and the
  successful response is silently dropped (the #78 failure mode). Extend
  the write deadline too (scanWriteTimeout).
- An oversized upload tripping MaxBytesReader was mapped to 400; it's 413.
  Detect *http.MaxBytesError and report IMAGE_TOO_LARGE.
- Split imagenorm error mapping: ErrTooLarge->413, ErrUnsupported->400,
  genuine read/encode faults (and a failed file.Open)->500, not 400.
- CreateFromPacket discarded the plant it created when the lot then
  failed, contradicting its own doc. Roll the new plant back instead so
  the confirm is all-or-nothing (a fresh plant has no lots/plantings, so
  the delete is safe; log-and-continue on cleanup failure).
- Dedup: packetLotRequest and seedLotCreateRequest shared every lot
  field. Extract a seedLotFields base both use. validCategory now reuses
  plantCategories. EffectiveConfig resolves agent+vision from one
  settings-row read instead of two.
- capabilities swallowed an EffectiveVision error silently; log it.
- vision test hand-copied Extract's body (drift risk). Split generate()
  out of Extract so the hermetic test drives the real request builder.

Tests: rollback-on-lot-failure (service), oversized->413 (api).

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

internal/api/settings.go

@@ -58,17 +58,14 @@ type effectiveView struct {
 }
 
 // settingsPayload builds the response, or an error. It does NOT swallow an
-// EffectiveAgent failure into a misleading empty "effective" view — an empty
+// EffectiveConfig failure into a misleading empty "effective" view — an empty
 // view would report no model and no key, which reads as "nothing configured"
-// rather than "we couldn't read it". Since EffectiveAgent re-reads the same row
+// rather than "we couldn't read it". Since EffectiveConfig re-reads the same row
 // GetInstanceSettings just returned, a failure here is a genuine DB fault worth
-// surfacing as a 500, not papering over.
+// surfacing as a 500, not papering over. It also resolves the agent and vision
+// views from ONE row read rather than fetching the single-row table twice.
 func (h *handlers) settingsPayload(c *gin.Context, st *domain.InstanceSettings) (settingsResponse, error) {
-	eff, err := h.svc.EffectiveAgent(c.Request.Context())
-	if err != nil {
-		return settingsResponse{}, err
-	}
-	vis, err := h.svc.EffectiveVision(c.Request.Context())
+	eff, vis, err := h.svc.EffectiveConfig(c.Request.Context())
 	if err != nil {
 		return settingsResponse{}, err
 	}