docs(v3): document *.field.list, and state the camelCase rule once

[IgorShevchik]

Closes #466. Documentation only — no SDK change, as the issue asked.

The gap

*.field.list / *.field.get appeared nowhere in docs/, skills/ or packages/.
The only place a reader could reach it was a comment on a playground command — somebody
needed the method, used it, and the answer landed in a demo. It is 91 of 245 methods
on the measured cloud portal: 37% of the v3 surface.

What the docs pointed at instead was the OpenAPI document: the right answer to which
methods exist, a heavy one to which fields does this entity have, and no answer at all
to filterable, editable and requiredGroups, which the request schema does not carry.

What lands

New page 8.discovering-entity-fields.md, numbered next to 7 because they are two halves
of one question; page 7 gained a pointer back.

Everything on it is measured first-hand. Six facts the issue listed as unverified or did
not have:

• sortable and filterable are independent. This is the one worth the page. On
  main.eventlog they name the same five fields of thirteen — a coincidence that reads
  exactly like a rule. On tasks.task they diverge: title is sortable: true,
  filterable: false, and one field of ninety-five is filterable at all. A reader who
  checks one flag and assumes the other is wrong on the second entity they try.
• <entity>.field.get answers with result.item — singular, not the result.items of
  .field.list. Assume symmetry and you get undefined.
• select narrows the descriptor keys: select: ['name', 'sortable'] returns rows
  with exactly those two.
• requiredGroups is null, not [], when nothing requires the field — iterate it and
  you throw. It reads ["add"] on tasks.task's title / creatorId / responsibleId,
  not the ["add","update"] the audit's reference recorded from the schema.
• The same refusal guards filter, not only order. tasks.task.list filtered on
  title answers HTTP 400 with Filterable in validation[].field, exactly as ordering on
  a non-Sortable field does. That matters because filterable has no other source — which
  is why the playground comment had to call this family in the first place.
• A field being returned says nothing about whether it may be sorted or filtered on:
  description is one of the thirteen main.eventlog.list gives back, and both flags are
  false.

Seven entities publish a .list with no .field.list — the four
crm.*.timeline.activity.email families, humanresources.access.permission,
humanresources.node.communication, rest.scope — where the issue knew of two on-premise.

The camelCase rule

Stated once, as a rule. It existed only as a per-method footnote — "most notably
tasks.task.list on v2" — while the code has encoded it as a default all along
(?? 'id' on v3, ?? 'ID' on v2). A reader told the rule predicts the next occurrence; a
reader given the footnote waits to be bitten by it. 108 descriptors across two entities,
not one uppercase initial.

Three lines taught it backwards and are corrected:

Where	What it said	Why it is wrong
99.examples/8.ai-assistant.md:47	"the deal lookup uses v3 (camelCase) fields"	The deal lookup is crm.item.get via actions.v2.call.make — an example that disproves the claim it is used to teach
skills/b24jssdk-filtering/SKILL.md:164	"v3-style methods (crm.item.list)"	v3 publishes no crm.item.* at all; crm.item.* is camelCase for reasons of its own
skills/b24jssdk-recipes/SKILL.md:130	"CRM v3-style methods"	same

The two v3 cursorIdKey rows illustrated the parameter with a v2 shape on a v3 page,
and now state the rule instead. The v2 rows already name tasks.task.list correctly and
are untouched.

Drive-by, from the same file

skills/b24jssdk-filtering/SKILL.md:141 promised DtoFieldRequiredAttributeException for a
non-Sortable field. The wire carries BITRIX_REST_V3_EXCEPTION_VALIDATION_REQUESTVALIDATIONEXCEPTION
— the specific class inherits it and gets no registry code of its own — with the
distinguishing detail in validation[].field. Matching on the message would fail anyway:
portals answer in the portal's language.

A prediction that held, recorded here because it is reusable

Widening the measuring webhook's scopes changed the OpenAPI document by zero methods —
245 before and after. #463's audit inferred "module-driven, not scope-driven" by comparing
two different webhooks; this is the same portal before and after, which is the stronger form
of the same claim. The committed snapshot therefore needs no refresh, and scripts/data/ is
untouched by this PR.

What is deliberately not here

No actions.v3.fieldList helper and no typed FieldDescriptor: it is an ordinary method
call.make already reaches, and a wrapper would re-import the per-portal knowledge 2.0.0
deleted with the allowlist. No field-name normaliser — the SDK must pass portal names
through unchanged or select echoes and filters break. The 91 method names are not
enumerated: the count is portal-specific (147 / 220 / 245 methods in total).

Checks

• docs-lint --strict — 0/0
• docs:lint-links — 0 broken (the new in-page links are site-absolute)
• docs:typecheck-blocks — 160 blocks, skills:typecheck-blocks — 83, both clean
• lint:v3-refs — clean, and the new page's method names are held against the committed
  portal snapshot from feat(scripts): hold v3 method names against a portal's own OpenAPI document #471
• lint:md — clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01F22e2ft66y7nuBJjzdThBr