Endpoint test depth: fuzz/adversarial ORM at trust boundary

[whisper67265]

Problem

The add-or-update endpoint lacked strict validation on several user-controlled fields (version, language codes, extensions, and collection sizes). Adversarial payloads—SQL injection strings, path traversal, control bytes, or oversized add_or_update maps—could pass serializer checks and reach Celery and ORM calls (Language.objects.get, Project.objects.get_or_create), weakening the trust boundary between HTTP input and database operations.

Acceptance Criteria

• version, organization, and language codes reject unsafe characters, path traversal, and inputs exceeding MAX_SEGMENT_LEN (256) with structured 400 responses before Celery is enqueued.
• add_or_update rejects empty/whitespace keys, invalid language character sets, more than MAX_ADD_OR_UPDATE_LANGS (50) keys, and more than MAX_SUBMODULES_PER_LANG (100) submodules per language.
• extensions entries must be strings; non-string elements produce validation errors, and all-blank lists normalize to None.
• Fuzz and adversarial tests confirm rejected payloads never call boost_add_or_update_task.delay, while valid payloads pass literal strings to Celery and ORM with user_id taken from authentication, not the request body.

Implementation Notes

• validate_language_code and shared _check_segment_length live in validators.py; serializer field validators aggregate multiple failures into structured BoostEndpointErrorCode responses.
• validate_version reuses validate_repo_segment and maps failures to INVALID_CLONE_URL, consistent with organization validation.
• TestOrmTrustBoundary monkeypatches Celery and ORM entry points to assert trust-boundary isolation without requiring live injection scenarios against the database.

References

• src/boost_weblate/endpoint/serializers.py
• src/boost_weblate/endpoint/validators.py
• tests/endpoint/test_serializers.py
• tests/endpoint/test_views.py