docs(skills/no-sql-web-sdk): surface CUSTOM-rule propagation gotcha in main pitfalls

The security-rule propagation window (backend caches rule evaluators for
2-5 minutes after managePermissions write) is already documented in
references/security-rules.md under 'Propagation And Verification'. However
agents loading the main no-sql-web-sdk/SKILL.md frequently do not drill
into the references file, so they finish configuring a CUSTOM rule and
immediately attempt the first write — which silently fails or returns
DATABASE_PERMISSION_DENIED because the rule has not propagated yet.

Seen in attribution issue_moasatof_tj63yv (CMS scaffold): agent correctly
set CUSTOM rules with auth.uid != null for create, but grader click-save
landed zero rows. Trace shows no wait or verification between rule-set
and first write.

Fix: add one pitfall bullet in SKILL.md that (a) warns about the 2-5
minute propagation window, (b) gives two working strategies (wait-retry
or verify-via-get), (c) reminds not to treat a resolved promise as
success, and (d) points to security-rules.md for the full pattern. Main
file content stays small; details remain in the reference.

Author: bookerzhao

config/source/skills/no-sql-web-sdk/SKILL.md

@@ -47,6 +47,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 - Using `wx.cloud.database()` or Node SDK patterns in browser code.
 - Initializing CloudBase lazily with dynamic imports instead of a shared synchronous app instance.
 - Treating security rules as result filters rather than request validators.
+- **Expecting a `CUSTOM` security rule to take effect immediately after you call `managePermissions(updateResourcePermission)`.** The backend caches rule evaluators for **2–5 minutes**; first writes after a rule change may silently fail or be rejected with `DATABASE_PERMISSION_DENIED` even when the expression is correct. Either (a) wait a few minutes and retry the same write before assuming the rule is wrong, or (b) verify the rule is live by reading `result.code` / `result.message` on every write and by doing a `get()` round-trip on the just-written `_id`; do not treat a resolved promise as success. See `security-rules.md` → "Propagation And Verification" for the full pattern.
 - Misreading the return shape of `db.collection(...).add(...)`. In the CloudBase Web SDK, the created document ID is exposed at top-level `result._id`, not `result.id`, `result.data.id`, or `result.insertedId`.
 - For CMS-style collections that need **app-level admin users** to edit/delete all records while editors can only edit/delete their own records, do not oversimplify the rule to `READONLY`. A validated pattern is a `CUSTOM` rule that reads role from `user_roles` by `auth.uid` and combines it with `doc.authorId == auth.uid`, while frontend writes can stay on `.doc(id).update()` / `.doc(id).remove()`.
 - Forgetting pagination or indexes for larger collections.