fix(tags): don't panic on tag filters with empty operands

[nikolauspschuetz]

Summary

ApplyTagFilter panics on a --tags filter that contains an empty operand.

matchAnd trims each operand and strips @, then immediately indexes tag[0]:

tag = strings.TrimSpace(tag)
tag = strings.Replace(tag, "@", "", -1)
if tag[0] == '~' {   // panics when tag == ""

Any filter that splits to an empty operand triggers runtime error: index out of range [0] with length 0:

• @one,,@two (double comma)
• @one, (trailing comma)
• ,@one (leading comma)
• @one&& (trailing &&)
• @one&&&&@two (double &&)

Since the filter string comes straight from user input (-t/--tags), a small typo crashes the whole run with a stack trace instead of a graceful result.

Fix

Guard the empty operand before indexing. An empty tag can never be present on a pickle, so it fails the AND — identical to what the existing else branch (contains(tags, "") → false) would compute if it were reachable — and is harmlessly ignored for the OR (comma) case:

tag = strings.Replace(tag, "@", "", -1)
if tag == "" {
    and = false
    continue
}
if tag[0] == '~' {

Tests

Added regression cases to Test_ApplyTagFilter for all five malformed filters above (each previously panicked; behaviour: @one,,@two → {p1, p2}, @one, → {p1}, ,@one → {p1}, @one&& → {}, @one&&&&@two → {}).

Verified:

• Reproduced the panic on main (index out of range [0] with length 0).
• go test ./internal/tags/ — passes with the new cases.
• go vet + gofmt clean.

[nikolauspschuetz]

One design note worth your call: this fix makes an empty operand forgiving — @one,,@two is treated the same as @one,@two (empty piece ignored for OR, fails AND), matching what the existing else branch already computes for a non-present tag. I went this way because ApplyTagFilter has no error return, so the alternative — rejecting a malformed filter with a validation error — would mean changing the signature and all callers, which felt like your decision rather than a drive-by. Happy to switch to a hard "invalid tag filter" error instead if you'd prefer strict validation over lenient tolerance.