refactor: deepen Deck and Card data-access modules

[lesnik512]

What

The DecksRepository / CardsRepository were empty subclasses of advanced-alchemy's service, so their interface was the entire generic surface and the query knowledge — filters, eager-load options, schema→model mapping — leaked into every HTTP handler.

This deepens both modules: a small set of named methods now absorbs that knowledge behind the interface.

Method	Absorbs
DecksRepository.fetch_with_cards(deck_id)	id filter + selectinload(cards)
CardsRepository.list_for_deck(deck_id)	deck_id filter
CardsRepository.add_cards(deck_id, cards)	model_dump + deck_id injection + Card(...) build
CardsRepository.upsert_cards(deck_id, cards)	same mapping, upsert semantics

Handlers now name the intent and hand over the request schemas they already hold.

Ports modern-python/litestar-sqlalchemy-template#26 to this template, adapted to FastAPI idioms (the typing.cast(...) response convention is preserved).

Scope (deliberately narrow)

• advanced-alchemy's generic surface stays visible (additive, not a narrowed interface) — the template still demonstrates the library.
• Methods return ORM models; output serialization stays at the HTTP edge via typing.cast.
• fetch_with_cards returns Deck | None — the existing 404 behaviour is byte-for-byte unchanged.
• list_decks / create_deck / update_deck / get_card left alone — they carry no real leak.
• No new tests: the existing HTTP suite already crosses all four methods.

Verification

• just test → 19 passed, 100% coverage (incl. repositories.py)
• ruff format --check / ruff check --no-fix / ty check clean

🤖 Generated with Claude Code