TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy.
In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called GenerateBlocks()
)
However, there's one potentially difficult thing with the way AES-CTR is used by Fortuna: Counters aren't reset upon re-key. So if Fortuna re-keys, it generates two blocks of key material and uses them as the new keys, but the counter used for this just gets incremented by 1 again and continued to be used.
This can be overcome by appropriately using the seeking mechanism of ChaCha.
In the end, AES-CTR in Fortuna fulfills the role of a pseudo random generator and thus is arbitrarily exchangeable by any other PRG, which includes block ciphers in CTR mode and of course also ChaCha. Whether using a different cipher will actually increase security depends on the amount of cryptanalysis on the new cipher, as 256-bit AES is already physically unbreakable for humans.
SHA-256d is used in two places in Fortuna: As a KDF to derive the new key from the old key and a given random string and separately as standard hash function to collect the pool entropy.
For both usages, a replacement of SHA-256(d) by Blake-2b is functionally equivalent, even though one may want to consider using Blake-2b in MAC mode (for the KDF part) or with some (distinct) personalization string for both operations.