fix: increase readiness probe timeout and period for all products

[Lytol]

Summary

• Raises TimeoutSeconds from 1s → 3s and PeriodSeconds from 3s → 5s on readiness probes for Connect, Workbench, PackageManager, and Flightdeck
• The 1s timeout was causing false readiness failures on healthy pods under load spikes (observed on Workbench)
• Liveness probes and all other probe fields (thresholds, initial delay) are unchanged
• No API/CRD changes — purely controller defaults; existing deployments will pick up the new values automatically on the next reconcile via a rolling update

Note that I also fixed the CLAUDE.md to use the appropriate nesting for worktree paths.

Test plan

• go test ./... passes (pre-existing failures in internal/controller/core are unrelated — missing kubebuilder etcd binary locally, reproduce identically on unmodified main)
• go vet ./... clean
• Deploy to a test cluster and confirm readiness probes reflect new values (kubectl describe pod)
• Verify no false readiness failures under normal and loaded conditions

[claude]

Claude finished @Lytol's task —— View job

---

Review Complete

• Read review guidelines
• Analyze diff and changed files
• Submit review

Submitted a review via the GitHub review system. The changes look good — the timeout/period increases are reasonable for addressing false readiness failures under load. Left one non-blocking suggestion about extracting the duplicated magic numbers into shared constants.

[claude]

Review Summary

Changes verified: The diff correctly updates TimeoutSeconds (1→3) and PeriodSeconds (3→5) on readiness probes for Connect, Workbench, PackageManager, and Flightdeck. Liveness probes are untouched. The CLAUDE.md changes fix worktree paths (unrelated but fine to bundle).

Controller checklist:

• ✅ Reconciliation remains idempotent — these are static defaults applied every reconcile
• ✅ No API/CRD changes required — values are hardcoded in controller logic
• ✅ Existing deployments pick up new values on next rolling update
• ✅ No security concerns (probe config only)

One suggestion (non-blocking):

The timeout and period values are now duplicated as magic numbers across four controllers (connect.go:731-732, workbench.go:934-935, package_manager.go:582-583, flightdeck_controller.go:349-350). Consider extracting shared constants like:

const (
    defaultReadinessTimeoutSeconds int32 = 3
    defaultReadinessPeriodSeconds  int32 = 5
)

This would make future tuning a one-line change and make intent clearer. The codebase already uses this pattern for defaultWorkbenchReadinessProbePath.

Note on FailureThreshold differences: Connect and Workbench use FailureThreshold: 3 while PackageManager and Flightdeck use FailureThreshold: 2. This is pre-existing and likely intentional (heavier products get more chances), but worth calling out for visibility.

LGTM — the values are reasonable for reducing false failures under load while still detecting genuinely unhealthy pods within ~15-25s.