Update version and changelog

Update the version and changelog after the 2.6 release.

Improve light/dark lookup and related image generator

This fixes three related problems I found while testing different scenarios with
light/dark/untagged logos:

1. Improved matching for two scenarios:
 - If you have 3 filerefs (light, dark, no tag) and request without a tag, you should
   get the untagged one.
 - If you have 2 filerefs (light, no tag) and request the dark tag, you should get the
   one with no tag.

These are edge cases that can sometimes work depending on what  order files are loaded
in, but the changes in ContestObject make sure it works predictably. Files are essentially
in three groups: things that match exactly, things that don't match but don't have a
conflicting/opposite tag, and everything else (i.e. conflicting tags). We look for
files in the first non-empty of these sets.

2. The ImageGenerator produces a contest logo/banner preview and an org logo preview,
each with images on a dark, grey, and white background. Prior to this it showed the
dark logo on the first two backgrounds and light on the white background. Now it tries
to find the best dark, no tag, and light logos respectively, which helps you understand
if you have all three or any combination which are likely to be loaded.

3. If you point at a contest location with no contest.json or .yaml (as we do with the
/shared folder for WFs), there is no 'contest', so we never try to load the contest logo
or banner. As a result, images/contest-preview.png is empty. This changes the disk
contest model to look for these resources when there is no contest.

Allow arbitrary tags while generating

Add compatibility section to main readme

Adds a new section to the main readme showing Java/spec version compatibility to be a
bit more explicit and clear.

Also fix two old/broken links in the CDS readme.

Handle null values for toTeamIds

When sending a broadcast (2023_06 spec), `to_team_id` is null,
and the code creates `[null]` for `to_team_ids`,
causing verification failure with:

Clarification to unknown team null
Clarification between teams

This is introduced from 39ac2647772a52aee5e3cce886a45b66bd7fa977

URL account tokens for reaction videos

Adds account-specific token parameters to reaction video downloads. Any client using
the url as-is (without basic auth) can download the file as the given user.
This allows (e.g.) web-based clients to pass the url to players like video.js that
support https but not basic auth.

The token is a one-way hash based on the account user and password. It is only
implemented for reaction videos for now to get some use and feedback, but could be
used for other 'file downloads' as well. Since all traffic is via https it could
probably use a simpler algorithm, but this can easily be changed later.

I moved the existing static method used to determine which account is making any
request to HttpHelper since it is not contest-specific, and added the new token
helpers there.

Example of reaction video in /submissions or event-feed after this change:
{"href":"contests/baku-live/submissions/1/reaction.webcam?token=DSjPuOj7OL9HLxEtMe0a5Mrl1vGCz2N2cO1bidDA=","filename":"reaction.webcam.m2ts","mime":"video/m2ts","tags":["webcam"]}],"contest_time":"0:07:47.704","time":"2025-05-26T09:55:53.702-04:00"}

Reaction video tagging

We record webcam and desktop for reactions videos, but there is only one reaction
property, so we've been serving desktop as one file and webcam as another, i.e.:

{"id":"2",... "reaction":[{"href":"contests/baku-live/submissions/2/reaction-webcam","filename":"reaction-webcam.m2ts","mime":"video/m2ts"},{"href":"contests/baku-live/submissions/2/reaction-desktop","filename":"reaction-desktop.m2ts","mime":"video/m2ts"}]}

The only way you could tell these part was based on the filename or url - but now the spec
has tags, which are a much better way to differentiate them.

This PR makes two changes: renaming the files to use '.' instead of '-' to match the variant
format in the draft spec, and adding support for these tags. The new output looks like:

{"id":"2",... "reaction":[{"href":"contests/baku-live/submissions/2/reaction.webcam","filename":"reaction.webcam.ts","mime":"video/mp2t","tags":["webcam"]},{"href":"contests/baku-live/submissions/2/reaction.desktop","filename":"reaction.desktop.ts","mime":"video/mp2t","tags":["desktop"]}]}

(file extension and mimetype already changed via PR #1236)

Add problem attachment support

Add attachments to problems as per https://github.com/icpc/ccs-specs/pull/226.

Improve mime type handling, especially for video

Fixes three things:

1. Move the existing utility functions out of DiskContestSource to create a reusable
   mime type utility class, to avoid some of the duplication and differences in
   behaviour.

2. The mime type wasn't being set when downloading reaction videos - but using the
   new util fixes this.

3. When we started supporting MPEG-TS there was conflicting information about the
   correct file extension and mime type, and based on google AI and video.js we got
   it wrong:

   MPEG Transport Stream (MPEG 2 transport stream) <-- this is what we actually support
   File extension: .ts
   Mime type: video/mp2t
   188-byte packets

   MPEG-2 Transport Stream <-- variant used by Blu-ray & AVCHD disks
   File extension: .m2ts
   Mime type: video/m2ts
   192-byte packets (4 bytes added to help file seeking)

   This switches us to use the file extension and mime type of the first.