refactor(docs): strip internal planning vocabulary

Removes internal roadmap IDs (IDX-01, MEAS-03, Phase 2, Phase 5) from
the cold-start deployment guide. No behavioral changes.

Author: ogabrielluiz

docs/docs/Deployment/deployment-cold-start.mdx

@@ -140,10 +140,10 @@ Starting with this release, `LANGFLOW_GUNICORN_PRELOAD` defaults to `true`. Guni
 
 Enabling `preload_app=true` makes any resource constructed before fork (the master process) shared with every worker via copy-on-write. Sockets and file descriptors are literally shared, not copied — a stale inherited HTTP pool, database engine, or background task will break.
 
-The Phase 5 audit covered seven classes of pre-fork state:
+The fork-safety audit covered seven classes of pre-fork state:
 
 - **SQLAlchemy engine.** Safe by construction — `DatabaseService.__init__` runs inside `initialize_services()` inside the FastAPI lifespan, which executes per-worker post-fork. The engine is never created in the master.
-- **asyncio locks.** Safe. `ComponentCache._lock` uses the IDX-01 lazy `@property` pattern introduced in Phase 2; each worker creates its own `asyncio.Lock()` on first access, bound to its own event loop.
+- **asyncio locks.** Safe. `ComponentCache._lock` uses a lazy `@property` pattern; each worker creates its own `asyncio.Lock()` on first access, bound to its own event loop.
 - **Component index cache.** Safe. `ComponentCache.all_types_dict` is populated inside the FastAPI lifespan (post-fork) by the wave-2 `asyncio.gather` block.
 - **Redis connection pool.** Safe (conditional). `RedisCache` is only constructed when `LANGFLOW_CACHE_TYPE=redis`, and in that case it is built inside `initialize_services()` (post-fork).
 - **asyncio background tasks at import time.** Safe. No `asyncio.create_task` calls at module scope; all tasks are created inside the lifespan body or inside `service.start()` methods.
@@ -172,12 +172,12 @@ For multi-worker deployments using the stock services, the default is recommende
 
 ### Measured improvements
 
-Phase 2 through 5.5 of the cold-start improvements milestone reduced `lfx run` and `langflow run` cold-start latency on Linux CI runners. Headline numbers from the post-fix authoritative run on Python 3.13:
+The cold-start improvements milestone reduced `lfx run` and `langflow run` cold-start latency on Linux CI runners. Headline numbers from the post-fix authoritative run on Python 3.13:
 
 - `lfx run` bare boot dropped from 17.82 s to 10.55 s (`lfx_bare` scenario).
 - `lfx run <flow>` uncompiled dropped from 18.92 s to 16.01 s (`lfx_with_flow` scenario).
 - `lfx run <flow>` with pre-baked bytecode dropped from 9.52 s to 8.43 s (`lfx_with_flow_prebaked` scenario).
 
 The gains come from in-process changes (deferred imports on the Graph hot path, atomic and version-stamped component index, parallelized lifespan tasks, event-driven MCP startup, persisted component-index cache) combined with the build-time and image-layer tunings documented above (`UV_COMPILE_BYTECODE=1`, multi-stage layer separation).
 
-For the full before / after table, per-scenario deltas, and MEAS-03 per-phase checkpoint breakdown, see the cold-start performance improvements entry in the [Langflow release notes](/release-notes).
+For the full before / after table, per-scenario deltas, and per-phase checkpoint breakdown, see the cold-start performance improvements entry in the [Langflow release notes](/release-notes).