Magic bitstream

Nobody has claimed this yet.

We've been facing undefined behavior with the latest commits' builds. These behaviors aren't deterministic: they only occur on some controllers. Some examples are:
- Not being able to write the correction matrix;
- Not being able to write the filters' coefficients;
- Not being able to sync DCC network;
- Some correctors having "pulsating" current readings.

The main hypothesis at the moment is a lack of timing constraints which is only revealed when the design becomes more congested.

There is a bitstream which is functionally identical to `master` (c86a1ea7fcd51e24f97d31fa725a06c02d3a3b8a) and works well, but it was built with a local commit that doesn't belong to git history anymore. I've pushed its [branch](https://github.com/lnls-dig/fofb-ctrl-gw/tree/magic-commit) and I'm attaching the bitstream to this issue.

[afcv4_ref_fofb_ctrl-2024-05-10-a46b56a4b4.zip](https://github.com/user-attachments/files/17512416/afcv4_ref_fofb_ctrl-2024-05-10-a46b56a4b4.zip)

Start by comparing the magic-commit branch and attached bitstream with master at c86a1ea7fcd51e24f97d31fa725a06c02d3a3b8a. Reproduce the controller-specific failures and investigate whether timing constraints explain the correction matrix, filter coefficient, DCC sync, and pulsating-current issues. Done means the affected functions behave deterministically on the controllers where they currently fail.

Written by the indexing model from the issue text.