since we need to compute hashSequences
For some sighashes you need it, for others you don't. Check how SIGHASH_SINGLE with SIGHASH_ANYONECANPAY is computed, based on examples. And if you move 54k sats input into over 200k sats output, then it would be valid, only if other inputs will put coins in, so even if someone else would copy-paste your signature somewhere else, your output will still get the amount you will pick.
Things to read about the way how Segwit scripts are validated for different sighashes:
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawikiBut what are the dangers of changing the nSequence?
As long as you don't use OP_CHECKSEQUENCEVERIFY anywhere in your transaction, it doesn't have that many consequences, even if it is enabled, and set to something else than 0xffffffff or 0xfffffffd. In that case, it affects mainly RBF (but since full-RBF, it is no longer important). And of course it affects signatures, if it is signed (but in some sighashes, some fields can be cleared).
Nice catch, if I would have went ahead to mine #7 I would have used a totally wrong value for this field (I was adding the sponsor's value here). That would have been fun (in the "what a disaster" kind of way).
I think you should first try everything on toy examples (like puzzle60 in testnet4, or make some local tests in regtest), and later attempt real puzzles, to not burn computing power for nothing. Because, just like in real block mining, if you mine invalid transactions, then you won't get any reward.