fix(library): correct unlimited-execution wording to acknowledge tunable admission defaults

Author: waleedlatif1

apps/sim/content/library/apache-2-0-vs-fair-code/index.mdx

@@ -83,7 +83,7 @@ Sim gives you three ways to run the platform on your own infrastructure, and eac
 - **Kubernetes.** Deploy with the provided manifests. Fits teams already running workloads on a cluster who want Sim to sit alongside them.
 - **`npx simstudio`.** Spin up a local instance in one command to prototype an Agent block or test a workflow.
 
-None of these paths caps how many users, workflows, or Agent block executions you run. The only ceiling is the compute, memory, and storage you provision. If you want a thousand people building with Chat and the visual builder, you size the database and runners to handle it, and nothing in the license or the software stops you. No seat counter, no execution meter, no phone-home check that throttles a self-hosted instance.
+None of these paths caps how many users, workflows, or Agent block executions you run. The only ceiling is the compute, memory, and storage you provision. If you want a thousand people building with Chat and the visual builder, you size the database and runners to handle it, and nothing in the license stops you. No seat counter, no usage meter, no phone-home check that throttles a self-hosted instance. The software ships sensible burst-protection defaults, such as a per-pod cap on concurrent in-flight executions, but those are plain environment variables you tune to your own hardware, not license gates.
 
 The terms stay identical across all three paths. The core you get from `npx simstudio` on a laptop is the core you deploy to a production cluster. Sim does not gate self-hosting behind a paid tier and reserve the permissive license for a stripped-down community build. That consistency matters when you plan a migration: prototype locally, promote to staging, move to production, all without switching license models or discovering a feature was reserved for a hosted plan.