feat(core): add sandbox target configuration for observed-IO opt-out - #36853

Review feedback: the target's sandbox configuration is copied onto each
Task in createTaskGraph (Task['sandbox'] equals
TargetConfiguration['sandbox']), so consumers read it off the task
instead of resolving it through the project graph. The orchestrator
registers it with the TaskIOService just-in-time in processTask, which
both run paths await before spawning, replacing the upfront iteration
over the task graph. The check-task-files sandbox matching is reverted:
those functions answer whether a file is an input/output, and with
ignored accesses excluded from reports at record time there is nothing
left for them to reconcile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YVrVQUAtU1aSQPuUxLkJsn

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YVrVQUAtU1aSQPuUxLkJsn

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YVrVQUAtU1aSQPuUxLkJsn

TargetSandboxConfiguration aliased the resolved napi shape, which has no
'...' member, so authoring a sandbox spread in TypeScript failed to compile
on a form the schema, the merge implementation and the PR's own test all
accept. The test needed an `as any` to construct it.

Adds Spreadable<T> and applies it to TargetConfiguration['sandbox'].
Task['sandbox'] keeps the resolved type, since merging resolves the token
away before a task is built.

sandbox rode the generic top-level merge, which assigns the object without
recursing into its values. mergeObjectWithSpread does a raw per-key copy for
the same reason, so a nested `'...'` was unresolved in BOTH the wholesale and
the object-spread branches: an inherited ignoredReads was silently dropped and
the literal '...' reached the task graph as a glob matching nothing. Nothing
rejects it, since the schema types the items as plain strings.

Gives sandbox its own merge, next to options and configurations. The object
level keeps replace-unless-'...' semantics, which the schema documents and the
existing specs pin; only the values now merge per key, so a nested spread
expands against the inherited value.

The merge copies before resolving. Without an object-level spread
getMergeValueResult returns the incoming object itself, so writing through it
would edit the caller's target in place and corrupt later merge layers.

The JSON schema is editor-only and nothing validated sandbox at runtime, so a
malformed value reached the task graph verbatim. Downstream consumers are
strict: a wrong-typed ignoredReads is rejected by the cloud runner's request
validation, failing the run rather than the target.

Validates the effective value during normalization, where the project, target
and source file are all still in hand, and throws naming all three. This runs
after every createNodes result is merged, so plugin-inferred targets are
covered too.

Checks shape only. A syntactically invalid glob is a well-formed string and is
deliberately out of scope.

sandbox had no section in the project configuration reference, while every
sibling target property does. The violation-fixing guide routed readers to
.nx/workflows/sandboxing-config.yaml with no mention that a per-target
property exists, so anyone following the official remediation path was steered
to the workspace-wide mechanism.

Adds the reference section, cross-links both directions, and states that the
two mechanisms combine rather than override. Also corrects the spread token
level table, which was presented as exhaustive and did not list sandbox.

isTaskSandboxDisabled had no production caller. Suppression happens inside
notifyPidUpdate, and the only reads were two assertions in its own spec that
sat alongside assertions on the observable behaviour they duplicated.

Confirmed unused by Nx Cloud before removing, rather than inferred from nx
alone: it consumes TaskIOService through getTaskIOService and the three
subscribeTo* methods only, and reads the opt-out off task.sandbox rather than
through the service.

Two regressions from the previous commits, both found by re-review.

The merge gated on `target.sandbox` being truthy while 'sandbox' was also in
skipForOwnMerge, so `"sandbox": false` was dropped from the merged target
entirely and validation never saw the exact input it exists to reject. Before
these commits that value survived to the napi boundary and threw there, so the
fix had turned a loud error into a silent one: the opt-out quietly did nothing.
Gating on key presence restores it. An array sandbox was also object-ified into
a valid empty config by the copy, so the guard now excludes arrays.

The per-key pass also keyed off Array.isArray alone and overwrote the
object-level merge's decision even where that decision was base-wins, so the
authored position of a glob array had no effect while `enabled` in the same
object still honoured it. It now skips keys authored before the spread that the
base already provides, matching how the target level computes the same set.

The validation specs built root maps the pipeline cannot produce, which is why
neither escaped there. They now also run through mergeCreateNodesResults.

isSupportedGlob rejects any pattern whose first segment contains '*', plus
'?', '!', '[', ']' and extglobs, so '**/generated/**' and '**/*.log' are
honoured while a task runs and then dropped from its snapshot. Those are the
first forms a user reaches for, and neither the schema description nor the
reference page said anything about it.

Documents the constraint in both schemas and the reference page. The silent
drop itself is a cloud-side fix; this is about the promise the schema makes.

The previous commit updated the two JSON schemas and missed the Rust doc
comment on TaskSandboxConfiguration, which is what a plugin author sees on
hover writing createNodes in TypeScript. That audience is the one most likely
to build a pattern programmatically and never open a schema. index.d.ts is
generated from the Rust and was regenerated.

The reference page also said an unsupported pattern is 'rejected'. Nothing
performs that action: nx validates shape only and never inspects glob syntax,
so there is no error at authoring time, at graph construction, or at run. A
reader who believes 'rejected' waits for a failure that never comes. It now
matches the schemas' 'not supported' and says plainly that the pattern has no
effect.

…aling CI Rerun]