Write a Kubernetes manifest that won't get OOMKilled at 2am because nobody set real resource limits

You are a senior software engineer producing Kubernetes manifests for a workload that's about to go into a shared cluster, where a badly configured resource limit or probe can take down more than just this one service. I'll give you the app details; you produce the manifests plus a note on every number you chose.

APP AND WORKLOAD TYPE
Stateless Go REST API, no local disk state, currently 3 replicas manually

OBSERVED RESOURCE USAGE
p95 CPU around 180m and memory steady around 220Mi under normal load, based on 2 weeks of Prometheus data; no data yet for peak traffic events

CLUSTER CONSTRAINTS
Shared EKS cluster, nodes are m5.xlarge, cluster-autoscaler scales nodes down aggressively overnight

TRAFFIC PATTERN AND STARTUP BEHAVIOR
Takes about 12 seconds to accept traffic after container start due to a connection pool warm-up; no slow JIT concerns since it's compiled Go

REQUIREMENTS
Set CPU and memory requests based on the observed usage given, not round-number guesses — requests should reflect steady-state usage so the scheduler doesn't over- or under-pack the node, and limits should give headroom for the traffic pattern described without being so loose that one pod can starve its neighbors. If observed usage isn't given for a number you need, say so explicitly and propose a conservative starting value with an instruction to revisit it after real metrics exist, rather than inventing a number that looks authoritative. Design readinessProbe and livenessProbe separately and explain the difference in consequence if each is misconfigured: a wrong readiness probe removes a pod from load balancing, a wrong liveness probe kills and restarts a container, which is a much more disruptive failure if the timing is wrong for a slow-starting app. Choose a rollout strategy (RollingUpdate parameters, or a note on why Recreate might apply) based on the startup behavior given, and set `maxUnavailable`/`maxSurge` values you can justify rather than leaving Kubernetes defaults unexamined. Include a PodDisruptionBudget if the cluster constraints suggest node maintenance or autoscaling events are a real risk for this workload.

WHAT NOT TO DO
Do not add a HorizontalPodAutoscaler, NetworkPolicy, or other manifest the user didn't ask about — list them as a separate 'you might also want' suggestion instead of inlining them into the required output. Do not set `limits` equal to `requests` by default (this causes CPU throttling under normal load) without explicitly confirming that's actually what's wanted here.

OUTPUT FORMAT
1. The full manifest YAML (Deployment, Service, and PodDisruptionBudget if applicable) in one code block.
2. A table of every resource/probe/rollout value chosen, the reasoning, and whether it's based on real data or a conservative placeholder.
3. A short 'you might also want' list of manifests not included.