rightsize: raise OOM-tight memory limits (batch 3/N — spike protection)

shlink 512->704Mi, linkwarden 1Gi->1280Mi, chrome-service 2Gi->2624Mi, forgejo 4Gi->5Gi, f1-stream 256->384Mi. All were request==limit with 30d peak at 91-100% of the ceiling — a spike would OOM-kill them. Raising the limit (now Burstable, request<limit) gives real burst headroom. This is the genuine 'don't OOM on occasional spike' fix. Small add (~2.2Gi limits) vs the ~20Gi of fat removed in batches 1-2, so net overcommit keeps dropping.

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

stacks/chrome-service/main.tf

@@ -321,7 +321,7 @@ resource "kubernetes_deployment" "chrome_service" {
               memory = "1500Mi"
             }
             limits = {
-              memory = "2Gi"
+              memory = "2624Mi"
             }
           }
         }

stacks/f1-stream/main.tf

@@ -143,7 +143,7 @@ resource "kubernetes_deployment" "f1-stream" {
           # 256Mi = upperBound x ~1.3 (bursty); requests=limits per convention.
           resources {
             limits = {
-              memory = "256Mi"
+              memory = "384Mi"
             }
             requests = {
               cpu    = "50m"

stacks/forgejo/main.tf

@@ -347,7 +347,7 @@ resource "kubernetes_deployment" "forgejo" {
               memory = "4Gi"
             }
             limits = {
-              memory = "4Gi"
+              memory = "5Gi"
             }
           }
           port {

stacks/linkwarden/main.tf

@@ -201,7 +201,7 @@ resource "kubernetes_deployment" "linkwarden" {
               memory = "1Gi"
             }
             limits = {
-              memory = "1Gi"
+              memory = "1280Mi"
             }
           }
         }

stacks/url/main.tf

@@ -232,7 +232,7 @@ resource "kubernetes_deployment" "shlink" {
           # }
           resources {
             limits = {
-              memory = "512Mi"
+              memory = "704Mi"
             }
             requests = {
               cpu    = "25m"