docs(showcase): drop two unverified runtime claims from the rewritten object comments

Self-review catch on this PR's own prose, not on the code. The rewritten comments
asserted two things this change never measured: that the objectui live e2e "no
longer depends on being admin" (that suite was not run here), and that "every
non-admin who clicked the entry got a 403" (no app was booted; the 403 is what
`nav-object-ungranted` REPORTS, not something observed).

Both are restated as what they are -- the lint rule's finding -- so the comments
claim exactly the evidence this PR carries and no more. A showcase comment is
read as documentation, so an overclaim there costs the same as an overclaim in
the docs.

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

Author: claude

examples/app-showcase/src/data/objects/cascading-select.object.ts

@@ -31,12 +31,14 @@ import { P } from '@objectstack/spec';
  * makes the object reachable: object-level CRUD (gate ①) comes only from a
  * permission set and is checked first. This comment used to say the wide OWD let
  * the seeded admin and the live e2e create records "without a bespoke permission
- * set"; what actually carried them was the admin's built-in WILDCARD set, and
- * every other member hit a 403 on the `nav_cascade` entry
- * (`nav-object-ungranted`, warned on every build). `showcase_member_default` now
- * grants read/create/edit, so the object is in the access-matrix snapshot and
- * the e2e no longer depends on being admin. Note where the narrowing really
- * lives: on one OPTION (`tier: 'restricted'`, admin-only), not on the object.
+ * set". What actually carried the admin was their built-in WILDCARD set: with no
+ * grant anywhere, `nav-object-ungranted` warned on every build and reports the
+ * `nav_cascade` entry as permission-denied for every principal that does not
+ * hold that wildcard set. `showcase_member_default` now grants read/create/edit,
+ * so the object is in the access-matrix snapshot and a plain member holds the
+ * capability the navigation entry already claimed for them. Note where the
+ * narrowing really lives: on one OPTION (`tier: 'restricted'`, admin-only),
+ * not on the object.
  *
  * The server verdict is unit-covered by objectql
  * `rule-validator.option-visibility.test.ts`; this object is the served fixture

examples/app-showcase/src/data/objects/expense-report.object.ts

@@ -40,8 +40,9 @@ export const ExpenseReport = ObjectSchema.create({
   // OWD let "any seeded persona create/edit reports without a bespoke permission
   // set" — measurably false, and the app shipped the proof: the object sat in
   // the shared navigation with no grant anywhere, so `nav-object-ungranted`
-  // warned on every build and every non-admin who clicked the entry got a 403.
-  // It worked for the seeded admin only, who holds the platform's wildcard set.
+  // warned on every build, reporting the entry as permission-denied for every
+  // principal except one holding the platform's built-in wildcard admin set.
+  // The seeded admin holds exactly that set, which is why it looked fine.
   // The grants now live on `showcase_contributor` (file/edit) and
   // `showcase_member_default` (read), and both appear in access-matrix.json.
   sharingModel: 'public_read_write',