docs(tenants): finish isolated-field removal and document opt-in policy labels (#481)

## What

Three-file update that closes out the `isolated` field removal in the v1
docs and documents the new opt-in network-policy label mechanism that
replaced it.

Changed files:

- `content/en/docs/v1/getting-started/create-tenant.md` — drop the
outdated Dashboard-tab bullet about the `isolated` checkbox, drop
`isolated: true` from the kubectl YAML example, and add an info callout
after the tabs block pointing at the upgrade notes and listing both
labels inline so readers of either tab see the same guidance.
- `content/en/docs/v1/operations/upgrades/_index.md` — expand the
pre-existing "Tenant `isolated` flag removed" stub with a target/label
table, a complete `Deployment` example that includes
`spec.selector.matchLabels`, and a short prose explanation that the
Cilium `allow-to-apiserver` policy matches via the `kube-apiserver`
entity rather than by hard-coded Service IP.
- `content/en/docs/v1/guides/tenants/_index.md` — add a new "Network
Isolation Between Tenants" section so operators landing directly on the
Tenant System guide learn about the mandatory isolation model and the
opt-in labels without having to read the upgrade notes.
- `content/en/docs/v1/operations/stretched/seaweedfs-multidc.md` —
remove the stale `isolated: true` from the two v1 Tenant YAML examples
and add a short note pointing at the upgrade guide so a reader comparing
with an older version of the doc understands why the field disappeared.

## Why

Two recurring pain points from the community chat:

1. Users still see `isolated` in examples (`create-tenant.md`,
`seaweedfs-multidc.md`) even though the field was deleted from the
`tenant` chart in Cozystack v1.0. Copy-pasting the old YAML leaves a
silently-ignored field in their manifests; in the worst case it breaks
validation on stricter admission setups.
2. With isolation now always on, the next question every time is *how do
I let my operator reach `kube-apiserver` from inside a tenant
namespace*. The answer is the two Cilium-policy-gated pod labels shipped
by the tenant chart (`policy.cozystack.io/allow-to-apiserver` and
`policy.cozystack.io/allow-to-etcd`), but they are documented nowhere
outside the chart source — users ended up discovering the labels by
reading `packages/apps/tenant/templates/networkpolicy.yaml` in the
upstream repo.

This PR documents both the removal and the replacement in the three
places a user is likely to land: the getting-started flow, the Tenant
System guide, and the v0→v1 upgrade notes.

## Verification

- `hugo` builds cleanly; all three affected pages render with the new
sections.
- Label names verified against
`packages/apps/tenant/templates/networkpolicy.yaml` in upstream
`cozystack/cozystack`:
- `policy.cozystack.io/allow-to-apiserver` → consumed by
`CiliumNetworkPolicy` `allow-to-apiserver` (egress to `kube-apiserver`
entity on port 6443).
- `policy.cozystack.io/allow-to-etcd` → consumed by
`CiliumClusterwideNetworkPolicy` `<tenant>-ingress-etcd`.
- The `kube-apiserver` Cilium entity claim is verified against Cilium's
[entity
documentation](https://docs.cilium.io/en/stable/security/policy/language/#entities-based).
- Hugo auto-generates `#tenant-isolated-flag-removed` from the heading
`Tenant \`isolated\` flag removed` (backticks are stripped, spaces
become hyphens); the three cross-file `{{% ref %}}` links resolve
correctly in the built site.
- `grep -rn "isolated:\s*\(true\|false\)" content/en/docs/v1/` after the
change only finds the intentional mention in `upgrades/_index.md`
describing the historical `isolated: false` behaviour — no stale YAML
examples remain.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Updated tenant configuration documentation to reflect removal of the
`isolated` field
* Added details on automatic Cilium-enforced network isolation for all
tenants
* Documented pod label requirements for accessing kube-apiserver and
etcd
* Added upgrade guidance for the `isolated` flag removal with migration
examples

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Author: kvaps

content/en/docs/v1/getting-started/create-tenant.md

@@ -71,9 +71,6 @@ doing so is **not recommended** for production environments.
     The `etcd` option is required for nested Kubernetes.
     Select it before installing the **Kubernetes** application in the tenant.
     Only disable it if you're certain the tenant won’t use nested Kubernetes.
-1.  The `isolated` option determines whether sibling tenants can communicate over the network.
-    This does **not** affect visibility in the dashboard.
-    In most cases, it should be enabled (i.e., isolation is on).
 1.  By default, no resource quotas are set.
     This means no usage limits.
     You can define quotas to prevent resource overuse.
@@ -106,7 +103,6 @@ spec:
     etcd: true
     host: team1.example.org
     ingress: true
-    isolated: true
     monitoring: false
     resourceQuotas: {}
     seaweedfs: false
@@ -124,6 +120,18 @@ kubectl -n tenant-root apply -f hr-tenant-team1.yaml
 {{% /tab %}}
 {{< /tabs >}}
 
+{{% alert color="info" %}}
+Cilium network policies in Cozystack v1.0+ always isolate sibling tenants from
+each other — there is no `isolated` field in either the Dashboard form or
+the HelmRelease values. Pods inside a tenant namespace also cannot reach
+`kube-apiserver` by default, or the tenant's own `etcd` when the tenant was
+created with `etcd: true`. To opt a pod into one of those paths, label it
+with `policy.cozystack.io/allow-to-apiserver: "true"` or
+`policy.cozystack.io/allow-to-etcd: "true"` respectively. See
+[Tenant `isolated` flag removed]({{% ref "/docs/v1/operations/upgrades#tenant-isolated-flag-removed" %}})
+in the upgrade notes for the full table and a worked example.
+{{% /alert %}}
+
 You can assist tenant users with installing database applications or nested Kubernetes clusters.
 As an administrator, you can switch context in the dashboard to access any tenant.
 Tenant users, however, can only access their own tenant and any child tenants.

content/en/docs/v1/guides/tenants/_index.md

@@ -55,6 +55,26 @@ Here's how this configuration will be resolved:
 ![tenant services](./tenants2.png)
 
 
+### Network Isolation Between Tenants
+
+Every tenant namespace is isolated from its siblings by Cilium network
+policies installed automatically by the `tenant` chart. There is no
+per-tenant opt-out: the previous `isolated` field was removed in
+Cozystack v1.0. Pods inside a tenant namespace also cannot reach
+`kube-apiserver` by default, or the tenant's own `etcd` when the tenant
+was created with `etcd: true` — they need to opt in with one of two pod
+labels:
+
+-   `policy.cozystack.io/allow-to-apiserver: "true"` — reach the
+    in-cluster Kubernetes API (for operators, dashboards, etc.).
+-   `policy.cozystack.io/allow-to-etcd: "true"` — reach the tenant's
+    own etcd (only applicable when the tenant was created with
+    `etcd: true`).
+
+See [Tenant `isolated` flag removed]({{% ref "/docs/v1/operations/upgrades#tenant-isolated-flag-removed" %}})
+in the upgrade notes for a full worked example.
+
+
 ### Unique Domain Names
 
 Each tenant has its own domain.

content/en/docs/v1/operations/stretched/seaweedfs-multidc.md

@@ -23,6 +23,11 @@ A convenient workflow is:
 
 ### 1. Create a Tenant without SeaweedFS
 
+The `isolated` field that earlier Cozystack releases exposed on the
+Tenant object was removed in v1.0. See
+[Tenant `isolated` flag removed]({{% ref "/docs/v1/operations/upgrades#tenant-isolated-flag-removed" %}})
+in the upgrade notes for the current network-isolation model.
+
 ```yaml
 apiVersion: apps.cozystack.io/v1alpha1
 kind: Tenant
@@ -33,7 +38,6 @@ spec:
   etcd: false
   host: ""
   ingress: false
-  isolated: true
   monitoring: false
   seaweedfs: false
 ```
@@ -77,7 +81,6 @@ spec:
   etcd: false
   host: ""
   ingress: false
-  isolated: true
   monitoring: false
   seaweedfs: true
 ```

content/en/docs/v1/operations/upgrades/_index.md

@@ -136,9 +136,53 @@ The migration is automatic for existing MongoDB instances.
 
 ### Tenant `isolated` flag removed
 
-The `isolated` field has been removed from Tenant configuration. Network isolation via
-NetworkPolicy is now always enforced for all tenants. If you previously relied on
-`isolated: false` to allow unrestricted traffic between tenants, this is no longer possible.
+The `isolated` field has been removed from Tenant configuration. Network isolation
+is now always enforced for every tenant via Cilium network policies — there is no
+per-tenant opt-out. If you previously relied on `isolated: false` to allow
+unrestricted traffic between tenants, this is no longer possible.
+
+Workloads inside a tenant namespace still need to reach a few control-plane
+targets (the in-cluster Kubernetes API server, the tenant's own `etcd`, and so on).
+The tenant chart ships a set of Cilium network policies that open these paths
+on an **opt-in** basis, gated on pod labels. If a pod inside a tenant namespace
+cannot reach one of these targets, add the corresponding label to its pod
+template:
+
+| Target | Label on the pod |
+| --- | --- |
+| The in-cluster Kubernetes API server | `policy.cozystack.io/allow-to-apiserver: "true"` |
+| Tenant-owned `etcd` cluster services (only applicable when the tenant was created with `etcd: true`) | `policy.cozystack.io/allow-to-etcd: "true"` |
+
+The `allow-to-apiserver` policy the tenant chart installs matches traffic
+against Cilium's built-in `kube-apiserver` entity, which Cilium resolves to
+the real API server endpoints. You do not need to know your Service CIDR or
+the address of the `kubernetes` Service — the label on the pod is enough.
+
+Example — allowing a Deployment's pods to reach `kube-apiserver`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-operator
+spec:
+  selector:
+    matchLabels:
+      app: my-operator
+  template:
+    metadata:
+      labels:
+        app: my-operator
+        policy.cozystack.io/allow-to-apiserver: "true"
+    spec:
+      containers:
+        - name: my-operator
+          image: example.com/my-operator:v1.0.0
+```
+
+Without the label, traffic to `kube-apiserver` is blocked by the
+`allow-to-apiserver` `CiliumNetworkPolicy` that the tenant chart installs in
+every tenant namespace. The same pattern applies to `allow-to-etcd`.
 
 ### Internal architecture changes