[docs] Style pass on the Ray Sandboxes networking section

[dstrodtman]

Description

Style-only follow-up on the "Networking and DNS" section added in #65570. No technical claim changes, and the section's structure and content are the author's; this is polish against the Ray documentation style guide.

I was asked for a docs review on #65570 but it merged before I finished, so the feedback is landing here instead of as suggestions on a merged PR.

What changed

The one pattern worth naming, because it repeats: the new prose was hard-wrapped at roughly 72 columns while the rest of the page uses one source line per paragraph. The guide asks for soft-wrapped prose so diffs stay legible.

Beyond that:

• Sentence splits where an em dash, a semicolon, or a mid-sentence colon was joining clauses. The guide asks us to restructure rather than punctuate. After this the whole page is free of Unicode dashes.
• ### DNS in locked-down networks instead of a bold paragraph lead-in. The guide reserves bold for UI elements, admonition lead-ins, and definition lists. As a real heading it also picks up a TOC entry and a linkable anchor. A note admonition would work too if you'd rather it read as an aside.
• Dropped — **recommended for internet access** from the public row's first cell. That's bold for emphasis, and the prose above the table already makes the recommendation.
• Parallel structure in the _oci_spec_transform_fn list. The second bullet had lost the **Term**: explanation shape of the first and grown to four sentences, so the migration guidance moves into prose after the list. This also drops "no longer need this hook," which orients a reader who knew the previous behavior rather than one arriving fresh.
• A complete lead-in above the network="public" example, which was a noun phrase with a colon on the end.
• Direct advice and active voice: "Prefer public for untrusted code" to "Use public", and "Anything beyond that can be configured" to "Configure anything beyond that."

One question I couldn't answer myself

The sandbox row's "Network access" cell reads "gVisor netstack," which says how the mode is implemented but not what the reader gets. Does network="sandbox" provide egress, or is it isolated like none? That's what someone scanning the table to pick a mode is asking, and it's the one cell that doesn't answer it. I left the cell alone rather than guess. Happy to add a few words here if you tell me which it is.

Related issues

Follows #65570. Related to #64964.

Additional information

DOCKER_DEFAULT_CAPABILITIES is in the sandbox package's __all__, so naming it in the prose above the example is safe. myst_heading_anchors = 4, so the new H3 and the existing #pass-custom-oci-configurations-to-gvisor link both resolve.

Note that no pre-commit hook covers Markdown under doc/source/, and Vale is scoped to the Ray Data docs and the example gallery, so nothing lints this file automatically. Verified by hand: heading depth tops out at H3, no stacked headings, and both in-page anchors match real headings.

[gemini-code-assist]

Code Review

This pull request improves the readability and structure of the Ray Core Sandboxes documentation, specifically refining the explanations for OCI specification transform functions, network modes, and DNS configuration in locked-down networks. The feedback suggests a minor improvement to the network modes table to clarify that the sandbox mode has no egress by default.

[gemini-code-assist]

To answer your question: yes, network="sandbox" runs gVisor's internal user-space network stack (Netstack). Since Ray Sandboxes do not configure external network interfaces for this mode by default, it has no egress/external connectivity (only loopback). It is isolated like none, but with a full network stack running inside the sandbox. We can clarify this in the table by updating the 'Network access' column to specify that there is no egress by default.

Suggested change

	| `sandbox` | gVisor netstack | untouched | Requires `rootless=False`. runsc doesn't support the sandbox netstack in rootless mode. |
	| `sandbox` | gVisor netstack (no egress by default) | untouched | Requires `rootless=False`. runsc doesn't support the sandbox netstack in rootless mode. |

[ronny-anyscale]

ignorable nits otherwise, pow

[ronny-anyscale]

Suggested change

	* **Namespace and mount details**: Configure namespace or mount behavior that the first-class options don't cover.
	* **Namespace and mount details:** Configure namespace or mount behavior that the first-class options don't cover.

[ronny-anyscale]

Suggested change

	* **Host mounts**: Mount host directories, read-only datasets, or model weights into the sandbox container.
	* **Host mounts:** Mount host directories, read-only datasets, or model weights into the sandbox container.

I have a feeling this list is longer than I see here and these suggestions are wrong for consistency, but here we are.

[dstrodtman]

The Read the Docs check on this PR is red for a builder-side reason, not for anything in the diff.

The build dies with a bare EOFError from multiprocessing/connection.py. doc/Makefile passes -j auto, so Sphinx forks one write worker per CPU, and when a worker dies the parent reports only that. Three things say it isn't this change:

• The failure point moves between builds. 92% of the write phase on build 4343129, 58% on build 4343286. A bad document would fail in the same place each time.
• The same signature hit master on build 4339216, and hit another PR that had passed an hour earlier on the same base.
• This diff is prose in a single Markdown file, which can't kill a subprocess.

I rebased onto current master to retrigger, and the fresh build failed the same way at a different document, which is what confirmed the read.

Measuring the builder's CPU count, cgroup memory ceiling, peak memory, and OOM counters is up in #65631 so the real cause can be pinned down. As the comments in .readthedocs.yaml note, the RtD PR check isn't a required merge gate, so this PR isn't blocked on that landing.