docs(linkedin): update Batch-08 LinkedIn posts with Argon review adjustments

docs/linkedin/batch-08-linkedin-posts.md

@@ -1,9 +1,9 @@
-# LinkedIn Technical Posts — Batch 08
+# LinkedIn Technical Posts — Batch 08 (Argon 审核定稿版)
 
 > **Target Audience**: CTOs, Engineering Directors, and Principal/Staff Hiring Managers in the US, Europe, and Singapore.
 > **Positioning**: Senior Full-Stack / DevOps / Platform Architect.
-> **Tone & Persona**: Authoritative, production-tested, quantitative, first-person singular (`I`), zero-fluff, no-homelab voice.
-> **Status**: Ready for publication / scheduling.
+> **Tone & Persona**: Authoritative, production-tested, quantitative, first-person singular (`I`), zero-fluff, no-homelab/no-shopkeeper voice.
+> **Status**: Approved by Consultant Argon (2026-11-01).
 
 ---
 
@@ -12,7 +12,8 @@
 * **Target Article**: `authentik-oidc-redirect-loop-node-set-header-overwrite`
 * **Canonical URL**: `https://blog.hoelee.com/posts/authentik-oidc-redirect-loop-node-set-header-overwrite/`
 * **Category**: Identity Architecture / Node.js
-* **Character Count**: ~2,050 chars
+* **Character Count**: ~2,100 chars
+* **Argon Verdict**: Approved
 
 ```text
 A custom admin portal failed with the most frustrating error a browser can show: ERR_TOO_MANY_REDIRECTS.
@@ -49,21 +50,24 @@ Verified end-to-end with Playwright headless browser automation: cookie preserva
 
 The hardest bugs are never the ones that crash. They are the ones where every layer quietly does exactly what you told it to do.
 
+Discussion: What is the most insidious "100% green metrics, 100% broken flow" silent failure you’ve diagnosed in production authentication pipelines?
+
 Full post-mortem and Playwright verification script:
 https://blog.hoelee.com/posts/authentik-oidc-redirect-loop-node-set-header-overwrite/
 ```
 
 ---
 
-## Post 02: Why Six Chrome Containers Locked a Production NAS (and Why Software WebGL Kills Storage)
+## Post 02: Why Six Chrome Containers Locked a Production Edge Storage Node
 
 * **Target Article**: `six-chrome-containers-locked-my-nas-btrfs-d-state-igpu-offload`
 * **Canonical URL**: `https://blog.hoelee.com/posts/six-chrome-containers-locked-my-nas-btrfs-d-state-igpu-offload/`
 * **Category**: DevOps / SRE / Storage Architecture
-* **Character Count**: ~2,200 chars
+* **Character Count**: ~2,250 chars
+* **Argon Verdict**: Approved (scrubbed hardware model to edge storage node)
 
 ```text
-At 09:42, every reverse-proxied service on a production DS1821+ NAS stopped responding. HTTPS handshakes established, SSL certificates validated, but backend requests hung indefinitely.
+At 09:42, every reverse-proxied service on a production edge storage node stopped responding. HTTPS handshakes established, SSL certificates validated, but backend requests hung indefinitely.
 
 SSH terminal load average: 27.42 on a 4-core AMD Ryzen V1500B.
 Memory: 7,410 MB used out of 7,842 MB. Swap: 3,980 MB used out of 4,096 MB.
@@ -80,17 +84,17 @@ What happened next was a textbook cascading kernel freeze:
 
 Because the Btrfs root transaction lock was held, every system process that touched the filesystem—PostgreSQL, proxy sockets, and internal managers—froze in the queue.
 
-The fix: separating storage from GPU-bound workloads.
+The fix: separating storage infrastructure from GPU-bound compute workloads.
 
 I migrated the browser automation fleet to an unRaid host powered by an Intel Core i9-13900K, passing through the integrated Intel UHD Graphics 770 (/dev/dri/renderD128). I also switched container policies from restart: unless-stopped to an on-demand model (0% CPU and 0 MB RAM when idle).
 
 Results:
-- Recovered 7.5 GB of committed memory (RAM + swap) on the NAS.
+- Recovered 7.5 GB of committed memory (RAM + swap) on the node.
 - Host load average dropped from 27.42 to 6.80 within minutes.
 - Sub-second response restored across all edge proxies.
 - Browser automation execution latency decreased by over 60% on native silicon.
 
-If you run browser automation on storage appliances, check your rendering flags before your filesystem locks up.
+Discussion: How do you architect resource boundaries for headless workloads to prevent containerized browser rendering from starving storage daemons?
 
 Full breakdown and Compose configurations:
 https://blog.hoelee.com/posts/six-chrome-containers-locked-my-nas-btrfs-d-state-igpu-offload/
@@ -103,7 +107,8 @@ https://blog.hoelee.com/posts/six-chrome-containers-locked-my-nas-btrfs-d-state-
 * **Target Article**: `cascading-docker-failures-nocodb-heap-limit-starved-n8n`
 * **Canonical URL**: `https://blog.hoelee.com/posts/cascading-docker-failures-nocodb-heap-limit-starved-n8n/`
 * **Category**: Systems Integration / High Availability
-* **Character Count**: ~2,100 chars
+* **Character Count**: ~2,150 chars
+* **Argon Verdict**: Approved
 
 ```text
 The alert triggered at 04:00: dozens of business-critical n8n workflows failed with `connect ECONNREFUSED :10380`.
@@ -131,6 +136,8 @@ Outcome: 100% workflow recovery, 0 connection drops, and stable 450 MB memory us
 
 Never set a Docker memory limit on a Node.js container without explicitly tuning --max-old-space-size to leave room for native memory.
 
+Discussion: Where do you draw the line between Docker cgroup limits and runtime internal heap tuning in production Node.js microservices?
+
 Full post-mortem:
 https://blog.hoelee.com/posts/cascading-docker-failures-nocodb-heap-limit-starved-n8n/
 ```