docs(deployment): the runtime publish gate now judges view writes too (#7220)

The surface table in `validating-metadata.mdx` was made wrong by the rule move
in this PR, in the two places a reader would actually rely on:

- it stated `flow` is the only metadata type any rule declares at the runtime
  publish door, and that "an object, view, page or dashboard save is checked by
  the schema parse and by nothing else". Both are now false for `view`;
- the `views[]` visibility-predicate family had no row at all, so the table
  could not say what that door does or does not judge about a predicate.

Adds the row with a `✓ᵛ` marker for `view` writes, corrects the footnote to name
both gated types, and records WHY the family crossed together — the property the
wiring guard now pins — since a reader who takes the table as a menu of
independently-wirable rules would draw exactly the conclusion #7220 was filed to
prevent.

The rest of the page was re-read and is unchanged: the "held to the CLI's
verdicts" paragraph, the 422 envelope description and the #6285 runtime-only
exception all remain accurate.

`content/docs/releases/v17.mdx` also references `@objectstack/lint` and is
release-owned — read, left untouched.

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

Author: claude

content/docs/deployment/validating-metadata.mdx

@@ -391,21 +391,32 @@ one. `sys_metadata` overlay rows are not in any config file, so there is no
 | View references — form targets, view-key collisions (#2554) | ✓ | ✓ | ✓ | — |
 | Flow authoring anti-patterns (#1874) | ✓ | ✓ | ✓ | ✓ᶠ |
 | Flow trigger readiness — a flow that looks armed and never launches (#5762) | ✓ | ✓ | ✓ | ✓ᶠ |
+| `views[]` conditional-visibility predicates — CEL syntax, parse budget, bare identifiers, binding-root layer, schema path refs (ADR-0089 D3b, #7010) | ✓ | ✓ | ✓ | ✓ᵛ |
 | Advisory: record titles, semantic field pointers (ADR-0085), seed replay/state safety, capability references, liveness | ✓ | ✓ | ✓ | — |
 | Package docs — flatness, prefixes, links (ADR-0046) | ✓ | ✓ | ✓ | — |
 | Undeclared authoring keys — every metadata collection (#3786) and the stack's own top-level keys (#4167) | ✓ | ✓ | — | — |
 | Naming, labels, data-model conventions, i18n coverage | — | — | ✓ | — |
 | Emits `dist/objectstack.json` | — | ✓ | — | — |
 
-**`✓ᶠ` means the rule runs at that door for `flow` writes.** `flow` is the only
-metadata type any rule declares there today — #4463 shipped P1 as one type and
-four rule families, and widening is a data edit nobody has made yet. So an
-object, view, page or dashboard save is checked by the schema parse and by
+**`✓ᶠ` means the rule runs at that door for `flow` writes; `✓ᵛ` for `view`
+writes.** Those are the two metadata types rules declare there today — #4463
+shipped P1 as one type and four rule families, and #7220 added the second type
+by moving the whole `views[]` visibility-predicate family across in one edit. So
+an object, page or dashboard save is still checked by the schema parse and by
 nothing else, and the `—` cells above are `—` for two different reasons: some
 rules read a stack-wide collection a one-item write does not carry (pages,
 dashboards, navigation, permission sets), and some parse authored source through
 `typescript`, which the kernel boot path must never load.
 
+The visibility family crossed **together**, and that is the point rather than an
+implementation detail. An earlier attempt wired one of its rules alone, which
+would have refused a `view` whose predicate names an unresolvable path while a
+predicate that does not parse *at all* saved clean through the same door —
+sibling verdicts about one predicate, one enforced, none predictable. A rule
+family is a wall, and a half-wired wall is worse than an unwired one, so
+`authoring-rule-wiring.test.ts` pins the property directly: every rule on that
+surface is gated at this door, or none is.
+
 Both halves of a gate's behaviour are on this door. Gating findings **refuse**
 the write, as the same `422 invalid_metadata` envelope a schema failure
 produces — `issues[]` carrying `rule`, `path`, `where`, `message` and `hint`, so