#8186 - No error if preset loaded to the library with empty <groupClass> provided

[mariam-khutuashvili]

Summary

Adds validation in Editor.updateMonomersLibrary to reject monomer group templates with an empty (or whitespace-only) class.
Previously silently dropped downstream by the consumer-side filter; now logs an error and skips the offending template while continuing to load the rest.

Spec

• groupClass is mandatory; valid values come from KetMonomerGroupTemplateClass enum (currently 'RNA').
• Per Ljubica's rule: incorrect property → skip the template, load the rest, throw error.

Changes

packages/ketcher-core/src/utilities/monomers.ts — new exported constant MONOMER_GROUP_TEMPLATE_CLASS_EMPTY_ERROR_MESSAGE.

packages/ketcher-core/src/application/editor/Editor.ts — new validation in the monomer group template loop, after the existing name-length check. Imports the new error message constant. Fires only when class is defined and trims to an empty string, so missing class (undefined) falls through to its own dedicated ticket.

packages/ketcher-core/tests/application/editor/Editor.test.ts — two new unit tests:

• should reject monomer group template with empty class — sends class: '', asserts error logged and template not added
• should reject monomer group template with whitespace-only class — sends class: ' ', asserts same

Tests reference the exported error message constant.

Check list

• unit-tests written
• e2e-tests written
• documentation updated
• PR name follows the pattern #1234 – issue name
• branch name doesn't contain '#'
• PR is linked with the issue
• base branch (master or release/xx) is correct
• task status changed to "Code review"
• reviewers are notified about the pull request

[claude]

Reviewed via /review-pr (code-quality, performance, documentation, security).

Overall: Small, well-scoped change. Consistent with the surrounding name-validation patterns, constant lives next to its peers in utilities/monomers.ts, error-message envelope mirrors the existing max-length log, and the tests follow the existing fixture style. No performance or security concerns.

One noteworthy item on the validation block itself — see inline. Everything else is either a stylistic nit (the two new tests could be a single it.each) or pre-existing (no JSDoc on updateMonomersLibrary and no public-API docs for the silent-skip-on-invalid behavior — both predate this PR).