[Feature]: Add missing garment types: tights, leggings as a first-class type, and more #211

Problem Statement

The garment vocabulary has gaps that make certain wardrobes hard to use. The clearest one for me is tights: the string tights appears nowhere in the repo, so it's neither in the prompt's TYPE list (backend/app/prompts/clothing_analysis.txt:6) nor in VALID_TYPES (backend/app/services/ai_service.py:58-89) nor in the manual dropdown
(frontend/lib/types.ts:195-227). The symptom is in issue #210 .

More broadly, looking at the 30 types as a set, they're weighted toward a casual wardrobe-and-jeans shape of dress.

Things I'd expect to find and don't:

• Legwear: no tights / pantyhose; leggings exists only as a pants subtype example (clothing_analysis.txt:10), never as a first-class type
• Intimates / base layers: no camisole, bodysuit, bra, underwear
• Footwear granularity: collapsed into four buckets (shoes, sneakers, boots, sandals). Heels, flats and loafers appear only as shoes subtype examples (clothing_analysis.txt:13), and subtype is never validated (ai_service.py:479) and has no picker in the UI
• Also absent: robe, pyjamas, overalls, sweatshirt (as distinct from sweater/hoodie), poncho

Worth noting: the feminine-coded items that are present (blouse, dress, skirt, jumpsuit, tank-top) are well covered on the subtype lists — dress gets seven subtypes at clothing_analysis.txt:11. The gap isn't that women's garments were deliberately excluded; it's that the list was built up casually and never pressure-tested against a different kind of wardrobe.

Proposed Solution

Extend the vocabulary with the missing types, keeping the existing structure. Concretely, at minimum:

• tights/pantyhose as a first-class type, mapped to a new legwear/underlayer role (see the separate role issue)
• leggings promoted from a subtype example to a real type
• camisole, bodysuit as first-class types
• heels and flats as first-class footwear types, or at minimum a controlled subtype vocabulary for footwear so shoes + heels survives validation

The change spans four hand-synced lists that need to stay in agreement:

Good news: no database migration is required. clothing_items.type is a bare String(50) with no CHECK constraint and no Postgres enum (backend/migrations/versions/001_initial_schema.py:204), so new types are purely a code change.

Per CONTRIBUTING.md:179-181 I'd add the new constants.types.* keys to messages/en/constants.json and leave the other seven locales to translators.

Alternatives Considered

• Adding them as subtype values only. Cheaper, but subtype is unvalidated free text with no UI picker, and it doesn't solve slotting — an item that's really a layer still can't be expressed to the outfit logic.
• A free-text "other" escape hatch with a custom_type column. More flexible long-term, but it needs a migration and gives up the validation that currently keeps the vocabulary clean. I'd rather see the real list filled in first.

Feature Area

Wardrobe Management (items, photos)

How important is this feature to you?

Critical - blocking my use case

Additional Context

I'm happy to open a PR for this. Main question is where the line should be drawn — my list above is based on my own wardrobe rather than a survey, so I'd rather someone with a broader view set the final scope.

Contribution

• I would be willing to help implement this feature