[docs] Add info on non isolated runs to hybrid (#25206)

## Summary & Motivation

`run-isolation.md` — the canonical Run isolation page. In the
Non-isolated runs section:
- Added that a non-isolated run executes in a new process inside the
already-running code location server (rather than provisioning a fresh
container) — this is the "where does the code actually run?" answer.
- Split the compute-resources description by deployment type:
- Serverless: 0.25 vCPU / 1 GB RAM (unchanged, just relocated into a
list).
- Hybrid (new): runs use the resources you configure for the code
location server, making Hybrid well-suited to time-sensitive,
low-compute jobs.
- Strengthened the caution: a non-isolated run that exhausts the
server's resources can crash it and disrupt other processes.
- Added a :::tip recommending Hybrid users run non-isolated jobs from a
dedicated code location, so an intensive run can't impact sensors,
schedules, and other code locations sharing the agent.

`hybrid/index.md` — the Hybrid landing page. Expanded the one-line Run
isolation blurb to mention that you control the code location server's
resources in Hybrid and that a dedicated code location is recommended,
then links to the full page.

## Test Plan

## Changelog

> The changelog is generated by an agent that examines merged PRs and
> summarizes/categorizes user-facing changes. You can optionally replace
> this text with a terse description of any user-facing changes in your
PR,
> which the agent will prioritize. Otherwise, delete this section.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Internal-RevId: 64d8697e1e3b91669b91942a2a62dfb10acd2c6a

Author: 2 people

docs/docs/deployment/dagster-plus/hybrid/index.md

@@ -37,7 +37,7 @@ If you are migrating from from Dagster+ Serverless, see the [Dagster+ Serverless
 
 ## Run isolation
 
-Dagster+ Hybrid deployments support both isolated and non-isolated runs. Isolated runs execute in their own container with dedicated resources, while non-isolated runs use a shared container for faster iteration during development. For details, see [Run isolation](/deployment/dagster-plus/run-isolation).
+Dagster+ Hybrid deployments support both isolated and non-isolated runs. Isolated runs execute in their own container with dedicated resources, while non-isolated runs use the persistent code location server for faster iteration during development or for time-sensitive jobs that don't require extensive compute. Because you control the code location server's resources in Hybrid, you can size them for the non-isolated runs you expect; running these jobs from a dedicated code location is recommended so they don't impact other processes. For details, see [Run isolation](/deployment/dagster-plus/run-isolation).
 
 ## Best practices
 

docs/docs/deployment/dagster-plus/run-isolation.md

@@ -29,9 +29,20 @@ If non-isolated runs are disabled (see the section below), the toggle won't appe
 
 ## Non-isolated runs
 
-Non-isolated runs provide a faster start time by using a standing, shared container for each code location.
+Non-isolated runs provide a faster start time by using a standing, shared container for each code location. Instead of provisioning a new container, the run executes in a new process within the code location server, which is already running.
 
-They have fewer compute resources than isolated runs. For Serverless deployments, non-isolated runs receive 0.25 vCPUs and 1GB of RAM. These resources are shared with other processes running within a code location like sensors. As a result, it's recommended to use isolated runs for compute intensive jobs and asset materializations.
+Because non-isolated runs share the code location server, they have fewer compute resources than isolated runs, and those resources are shared with other processes running within the code location, such as sensors and schedules. The available resources depend on your deployment type:
+
+- **Serverless:** Non-isolated runs receive 0.25 vCPUs and 1GB of RAM.
+- **Hybrid:** Non-isolated runs use the compute resources you've configured for the code location server. Because you control the code location server's resources, Hybrid is well-suited to non-isolated runs for time-sensitive jobs that don't require extensive compute.
+
+We recommend using isolated runs for compute-intensive jobs and asset materializations. A non-isolated run that exhausts the code location server's resources can crash the server and disrupt other processes running within the code location.
+
+:::tip
+
+For Hybrid deployments, run non-isolated jobs from a dedicated code location. Isolating these jobs in their own code location server ensures that an intensive (time, memory, or CPU) run can't impact the sensors, schedules, and other code locations that share an agent.
+
+:::
 
 To be able to use non-isolated runs, the `non_isolated_runs` setting must first be enabled in [Full deployment settings](/deployment/dagster-plus/deploying-code/full-deployments/full-deployment-settings-reference#non-isolated-runs):