chore: remove orphaned @event JSDoc blocks (post-CEM cleanup)

[web-padawan]

Summary

Now that #11539 has migrated web-types and API docs generation to CEM, event documentation is canonically expressed via @fires {CustomEvent} <name> - … lines on the class JSDoc. CEM does not read @event JSDoc blocks at all.

The 2026-04-29 batch (#11604–#11610) plus follow-up #11619 copied long descriptions from @event blocks into the corresponding @fires lines. The @event blocks remained in source as duplicate dead documentation.

This PR removes them: 129 blocks across 49 .js files, ~928 lines deleted. Concentrated in:

• charts (34 blocks in vaadin-chart-mixin.js)
• upload (13 blocks)
• grid (12 blocks)
• dashboard (7 blocks)
• overlay, crud, combo-box, dialog, date-picker, confirm-dialog, plus 22 other packages with 1–3 blocks each

.d.ts files are untouched.

Verification — web-types output is byte-identical

Per the user's stated success criterion. Snapshotted custom-elements.json and all 120 per-package web-types.json / web-types.lit.json files before the cleanup, applied the change, regenerated everything, and confirmed via diff -r that every per-package output is byte-identical.

# Before changes:
yarn release:cem && yarn release:web-types
mkdir -p /tmp/cem-before
for f in packages/*/web-types.json packages/*/web-types.lit.json; do
  mkdir -p /tmp/cem-before/$(dirname "$f"); cp "$f" /tmp/cem-before/"$f"
done

# Apply this PR's diff, then:
yarn release:cem && yarn release:web-types
diff -r /tmp/cem-before/packages packages/   # empty ✓

The root custom-elements.json shows module-ordering variation between runs (a pre-existing CEM-analyzer non-determinism), but every module's content is identical when sorted by path. Per-package CEM output that's published to npm is unaffected.

Note on @param detail.* documentation

A handful of @event blocks (in vaadin-upload.js, vaadin-chart-mixin.js, vaadin-crud-mixin.js) included @param detail.* lines describing the detail object's shape. The shape itself remains fully captured by the CustomEvent<{…}> type parameter on the *Event type aliases in .d.ts files (e.g., UploadBeforeEvent = CustomEvent<{ xhr: XMLHttpRequest; file: UploadFile }>), which IDE / TS users consume directly. The @param detail.* lines were never read by Polymer Analyzer or CEM — they were inline source-only prose.

If a specific @param detail.x description is judged worth preserving, it can be lifted into the affected component's @fires line in a follow-up.

Test plan

• yarn release:cem and yarn release:web-types produce byte-identical per-package output vs. the pre-change snapshot
• yarn lint and yarn lint:types pass
• git diff --stat -- 'packages/*/src/*.d.ts' is empty (.d.ts files untouched)
• Spot-check that @fires lines are still present and unchanged on the affected components
• CI tests pass

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud