The seed could be the hash of all transaction in the previous CB. You can't control the value of a hash, that's a major point of hashes: you can't find the content of a transaction which, when concatenated with the other transactions, will result in the given hash value. So you can't control the seed even if you control a part of the transactions.

Furthermore, you have very limited control of IDs of your SHs. They're assigned by the order of their appearance. And they're decided before the seed for the next CB is decided.

Since there is no control of the random generator, you'll have to resort to bruteforcing it. In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof. Maybe it's easier to deal with the possibility of bruteforce search of a favorable seed. If the proportion of shares that you own is p, to have n consecutive TBs you'll have to enumerate (1/p)^n seeds. For n=360, an hour of disruption, and p=0.9, a 90% attack, you will need to enumerate 29695907506101728.772544490140544 seeds on average. We can live with that.