MARISSA MOLEJON | OCT2025-1 | Module-Legacy-Code | Sprint 1 | fix bloom length limit - #2

Summary

blooms longer than 280 characters could be stored, because
the character limit was only enforced in the frontend and never
validated by the API.

Fix

Added a MAXIMUM_BLOOM_LENGTH = 280 constant and a length check in
send_bloom(), mirroring the existing MINIMUM_PASSWORD_LENGTH
validation pattern already used in register():

if len(request.json["content"]) > MAXIMUM_BLOOM_LENGTH:
    return make_response(
        (
            {
                "success": False,
                "message": f"Bloom must be no more than {MAXIMUM_BLOOM_LENGTH} characters long",
            },
            400,
        )
    )

No frontend changes were needed — front-end/lib/api.mjs's existing
generic error handling (_apiRequest → handleErrorDialog) already
surfaces any {success: false, message: ...} 400 response, the same
way it does for the "Incorrect password" error, so this new
validation error displays correctly with zero additional UI work.

Testing

Verified manually via curl against a running local backend:

• ✅ Content of 300 characters → rejected, 400, correct message.
• ✅ Content of exactly 280 characters → accepted (boundary is
  inclusive, no off-by-one).
• ✅ Content of 281 characters → rejected (confirms the boundary is
  exactly at 280, not 281 or 279).
• ✅ Normal, well-under-limit content → still accepted, unaffected.

Scope / Known follow-up

This PR only adds validation for new blooms going forward. It does
not retroactively clean up existing over-length data already in
the database (e.g. the seeded bloom on AS's profile referenced in
the issue). That's a data-cleanup concern, not a validation bug, and
involves a separate judgment call (truncate vs. delete vs. leave as
a grandfathered exception) that felt out of scope for this fix. Happy
to open a follow-up issue if the reviewer wants that addressed.