borg2: Allow comma-separated archive IDs in `aid:` matcher

[PhrozenByte]

The aid: archive match pattern currently matches exactly one archive ID. Multiple -a / --match-archives options are combined using AND semantics, so there is currently no convenient way to explicitly select multiple archives by their unique IDs.

For example, the following does not match either archive, since an archive cannot have both IDs:

$ borg2 repo-list -r /run/media/daniel/prometheus/Borg/ -a aid:8961fcf1 -a aid:466b7c4d
Command error: archive ID based match needs to match precisely one archive ID

Suggestion

Allow aid: to accept a comma-separated list of archive IDs, with OR semantics within the pattern. All archive IDs given must still match exactly one archive.

For example:

$ borg2 repo-list -r /run/media/daniel/prometheus/Borg/ -a aid:8961fcf1,466b7c4d
8961fcf1  Mon, 2026-08-24 11:24:32 +0200  Tuxedo-InfinityBook-14              daniel      Tuxedo-InfinityBook-14  Arch Linux (Last Update: 2026-08-20T00:1
466b7c4d  Tue, 2026-08-25 12:21:14 +0200  Tuxedo-InfinityBook-14              daniel      Tuxedo-InfinityBook-14  Arch Linux (Last Update: 2026-08-24T15:4

This could retain the current behavior for a single ID while providing a simple way to explicitly select multiple known archives.

Benefits

This would

• allow explicitly selecting multiple unique archives,
• avoid requiring multiple matcher options with different semantics,
• make aid: more useful for scripts and other programmatic archive selection,
• allow processing multiple explicitly selected archives in a single borg2 invocation instead of running borg2 separately for each archive, which can reduce overall runtime.

[PhrozenByte]

tags: patterns already support comma-separated tags, but these are matched with AND semantics within a single pattern. Since this syntax is currently undocumented (docs use -a 'tags:TAG1' -a 'tags:TAG2' as example), we could change the semantics to OR without breaking documented behavior. AND semantics can still be achieved with multiple separate patterns, so having AND semantics within a single pattern is redundant.

Neither user:, host:, nor date: support comma-separated values yet, though. As a future enhancement, it might be reasonable to add the same behavior there as well.

For name patterns, comma-separated alternatives would be a little hard to get right due to the different pattern styles (and with re: patterns, one can already achieve this), so I wouldn't support them there. If things get that complicated, one should probably use tags instead; giving users this flexibility is exactly what they're for.

These changes could be implemented together or separately; I can open separate issues for them if desired.