Enforce a single fixture announcement channel per guild

[adrunkhuman]

Problem

Fixture announcements currently go to whichever channel an admin uses for /admin fixture create.

That keeps the implementation flexible, but it also means the bot has no single canonical fixture channel per guild. In practice this creates avoidable complexity:

• startup verification has to infer where fixture announcements live
• operational expectations are less clear for admins
• permissions become noisier than they need to be
• the bot can drift into a "fixtures can appear anywhere" model that this project does not really need

For this bot, the real-world usage is closer to "one server, one fixture channel".

Proposed direction

Make the announcement channel an explicit product rule:

• each guild has one configured fixture announcement channel
• fixture creation is only allowed from that channel, or always posts there regardless of where the command was run
• startup verification only checks that configured channel

This is intentionally opinionated. The goal is to reduce operational ambiguity and keep the bot simple for a small personal league setup.

Why this is better than a narrow bug fix

Storing channel_id per fixture would reduce startup scanning, but it preserves a more flexible model than the project actually needs.

If the intended product is "fixtures belong in one known place", the better fix is to encode that rule directly instead of adding more per-fixture metadata to support a looser workflow.

Suggested implementation

• add guild-level config for the fixture announcement channel
• validate fixture creation against that configured channel
• update announcement posting to always use the configured channel
• simplify startup verification to only inspect that channel
• document the rule clearly for admins

Acceptance criteria

• each guild has one canonical fixture announcement channel
• fixture announcements no longer depend on where /admin fixture create was invoked
• startup verification no longer scans unrelated channels
• permission warning spam is reduced or eliminated
• admin UX makes the required channel obvious

Context

• Follow-up from startup verification warnings and noisy channel scanning