deploy: add --provision_only to provision resources without rolling out servers

[ns-kosti]

What

Adds ns deploy --provision_only, which provisions a stack's resources (e.g.
applies Postgres schema) without rolling out the requested servers. This lets
resource provisioning run as its own step — for example, applying database
schema as a gated CI step that can fail before any application rollout.

ns deploy --provision_only ./app   # ensure DB + apply schema, no app rollout
ns deploy ./app                    # roll out the app

Why

The resource provider that applies database schema runs as part of every
deploy and emits the connection instance the servers consume. Today there is
no way to run that provisioning on its own. Splitting it out enables:

• running migrations as a separate, reviewable pipeline step;
• failing early, before rolling out servers;
• running provisioning with narrower credentials than a full deploy.

Note: a subsequent ns deploy still re-runs the provider, because resource
instances are produced per-deploy and consumed to build each server's runtime
config — they are not persisted between deploys. This change re-orders
provisioning into its own step; it does not remove it from the rollout deploy.

How

provision-only is a deploy planning mode (PrepareDeployMode), not a filter
over the assembled plan:

• Server deployables are filtered out of the typed DeploymentSpec before
  deployment planning, so the requested servers and their runtime-config ops
  are never emitted.
• Servers that resources require (e.g. a colocated database) are kept, derived
  from the server-resources discovered while planning resources.
• A no-op OpConsumeResourceOutputs invocation consumes the resource instance
  outputs that the dropped servers would have consumed, so the plan's output
  accounting stays balanced.
• Runtime ingress is skipped, so no routes are created for servers that are not
  rolled out. Ingress-as-resource fragments deploy through the same path and
  are likewise not applied.

Testing

• go test ./internal/planning/deploy/...
• Unit tests cover the two correctness-critical helpers: keeping only
  resource-required servers, and building an output sink that consumes every
  produced resource instance.

Notes

• Independent of any other in-flight change.
• Commits are organized to be reviewed one at a time.