We have no way of checking "uses" lists for tasks

Mechanisms like task_slot let tasks declare relationships to other tasks, which we then fill in in the configuration. If you attempt to bind a task slot that doesn't exist in the code, you get an error. If you miss a task slot, you get an error. This is nice.

The uses mechanism for binding tasks to memory-mapped peripherals predates that mechanism by ~1yr and has no such niceties.

It would be neat to fix that. A fix would probably involve

• Tasks grow some way of declaring that they use a peripheral, either by name or maybe by address. (The address does wind up getting baked into the task at compile time, so doing it by address might be more reliable.)
• The build system grows a way of noticing these and checking compatibility with the uses list.

This would also let us warn if the task has more uses items than it needs --- which interacts nicely with the build system task packing changes, because freeing up region table entries means a task can be packed tighter.

Start by tracing the existing task_slot and uses mechanisms, then inspect how the build system assembles task configuration and memory-mapped peripherals. Done means tasks can declare their peripheral requirements, incompatible or missing uses entries are reported, and unnecessary uses entries produce warnings.