fix(cli): label a deck with the language it declares

[jvsena42]

Closes #225.

What was wrong

deck create and import accepted --front-lang/--back-lang, wrote them into the manifest, and stopped there. The ordinary tags a declared pair is supposed to contribute — "spanish", plus the "language" umbrella (LanguageTags, Architecture §7.7 point 4) — were never derived.

$ loopky deck create --env staging --title "lang tag probe" \
    --front-lang en-US --back-lang es-ES --listen --speak --json
tags: []
pair: en-US -> es-ES

The labels are the entire reason the pair contributes a tag at all: a tag record is the only thing Loopky publishes that a network-wide index can answer questions about. So a deck imported with loopky import deck.apkg --front-lang ja-JP --back-lang en-US was invisible to tag browse, to tag trending and to anyone on Nexus looking for Japanese decks — while the byte-identical deck published from a phone was not, because PublishDeckViewModel and DeckEditorViewModel both route a language pick through LanguageTags.retag. Only the headless path skipped it.

Nothing reported it. The deck published, --json said ok, deck show printed the pair, and the only symptom was a search that came back empty somewhere else entirely. Bulk .apkg import is the job the CLI was built for (#46), which made this the path where the most decks arrived and the least were discoverable.

What changed

Every path that sets a pair now goes through LanguageTags where the apps go through it on the pick:

• Decks.kt → deckCreate
• Import.kt → newDeck
• Import.kt → overlaidWith, the --resume overlay — which also has to drop the previous pair's labels, since a resumed run can move the pair

deck edit already did it, but only when the pair actually moved. It now reconciles whenever the invocation names a pair. That is the answer to the first thing the issue left open:

Existing decks. Anything the CLI has already published with a pair is missing its labels and will stay missing until someone edits it.

Restating the pair a deck already has is the repair, so the workaround the issue described — retype the deck to a different region of the same language and back — is gone rather than documented. Reconciling nothing is still not a write, because changedFieldsFrom diffs.

And the second:

The interaction with deck edit --tag. --tag replaces the set, deliberately (#222).

It still does, and the two commands now agree out loud: naming a pair reconciles the labels, naming none leaves them alone. So --tag verbs on a language deck drops them, --clear-tags really does empty the set, and passing the pair alongside either one puts them back. They are ordinary author-removable tags, not a reserved family, so those gestures have to be believed.

Not all decks are language decks, and that is the invariant with the most tests on it: LanguageTags.forPair returns nothing for a deck that declares no pair, umbrella included, so "language" never lands on a deck of capital cities.

Verification

11 new tests in DeckLanguageTagsTest across all four paths, plus a run against live staging with a real session, recorded in journeys/RESULTS.md:

Step	Result
The issue's own probe, re-run	[language, english, spanish] — was []
deck show in a fresh process	on the homeserver, not just in the cache
deck create --tag geografia, no pair	[geografia] — no umbrella
deck edit --clear-tags on a language deck	[]
deck edit restating the pair it already had	labels return
import --tag core --front-lang ja-JP --back-lang en-US	[core, language, japanese, english]
import --resume --back-lang pt-BR	english dropped, portuguese added
import --resume with no flags	unchanged, no metadata write
tag trending --env staging	language/english/portuguese/spanish rank on Nexus

Three throwaway decks, created and deleted in the same run. ./gradlew :cli:test :shared:jvmTest detektAll green. No UI touched, so no journeys/*.xml needed re-running.

🤖 Generated with Claude Code

https://claude.ai/code/session_0116NZ92Pe7aGQpqtiRkP4Ye