docs(spec): the SelectOptionSchema visibleWhen docblock qualifies each number of its objectui pair

Claude-Session: https://claude.ai/code/session_014EJ1ED8X4MMrT18BhVx4tx
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/spec-field-option-visiblewhen-pair-qualified.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/spec': patch
+---
+
+A field-option docblock names both sibling issues by repository
+
+The docblock on `SelectOptionSchema`'s `visibleWhen` in `src/data/field.zod.ts` cited a pair
+of objectui issues as `objectui#6110 + #6111`, which reads the second number as
+this repository's. It now qualifies each number on its own, so both point at the
+objectui records the sentence describes. Comment only: no type, schema, export
+or runtime behaviour changes.

packages/spec/src/data/field.zod.ts

@@ -367,7 +367,7 @@ export const SelectOptionSchema = lazySchema(() => strictObject({
    * Options resolve through `resolveCascadingOptions` against that scope
    * (ADR-0068 / objectui#2284), while field- and section-level rules go through
    * `evalFieldPredicate` — a different evaluator, but since objectui#6010 (field)
-   * and objectui#6110 + #6111 (section) it is handed the same host scope, so
+   * and objectui#6110 + objectui#6111 (section) it is handed the same host scope, so
    * `current_user` resolves on those surfaces too. What still separates this one
    * is ENFORCEMENT, not vocabulary: per-option `visibleWhen` is the only
    * VISIBILITY predicate the SERVER also evaluates — the rule validator refuses