feat(atomize): serve Subdivide via Anypreta Issue Atomizer

Add an optional remote atomization backend (the Anypreta "Issue Atomizer"
API) for the Subdivide flow, selected by ATOMIZER_REMOTE_BASE_URL /
ATOMIZER_REMOTE_API_KEY. When set, POST /v1/atomize is served by the remote
/v1/atomize-issue endpoint; its two-level issue→features→tasks model is mapped
onto our one-level task→children model by treating each Feature as a child and
its `estimation` as the effort coefficient (renormalized to sum to 1, even
split as a reported fallback when estimations are absent).

Extend and Summarize have no counterpart in the remote API and always stay on
ATOMIZER_BASE_URL, so the §5.1 service must keep running; readiness now probes
both backends. The mandatory `system` object is derived from the customer,
with a generic component tree (an empty tree makes the service return zero
features).

extsvc also learns the remote's flat error envelope ({error_code,message} and
FastAPI {detail}) and never swallows an unrecognized 4xx body.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

internal/atomize/service.go

@@ -99,6 +99,15 @@ func (s *Service) HandleSubdivide(ctx context.Context, job *jobs.Job) error {
 		Attachments:        s.requestAttachments(t),
 		Links:              taskLinks(t),
 		SubdivisionNote:    p.Note,
+		CustomerID:         t.CustomerID,
+	}
+	// Project context for backends that need it (the Anypreta `system`
+	// object). Not worth failing an atomization over.
+	if cust, err := s.st.CustomerByID(ctx, t.CustomerID); err == nil {
+		req.CustomerName = cust.Name
+	} else {
+		s.log.Warn("subdivide: customer lookup failed, sending id only",
+			"task", t.ID, "customer", t.CustomerID, "err", err)
 	}
 	if p.MinTasks > 0 || p.MaxTasks > 0 {
 		req.Constraints = &Constraints{MinTasks: p.MinTasks, MaxTasks: p.MaxTasks}