Reject mixed input mass variants in client tx conversion

[michaelsutton]

Background and questions:

• compute_budget is the new input mass commitment field for newer transaction versions (1+)
• it has finer granularity and a wider u16 range than sig_op_count, so it can support broader script pricing
• the overall strategy was:
  • in consensus-core, model input mass as an enum for internal consistency
  • in RPC and client-facing types, add compute_budget alongside the existing field for backward compatibility
• this creates a question of where version consistency should first be enforced
• this PR takes the position that, where possible, it should be enforced at the client-to-consensus conversion boundary
• once the version is known, the conversion already knows which input-mass field is valid, so these combinations are clear misuse:
  • v0 transaction with non-zero compute_budget
  • v1+ transaction with non-zero sig_op_count
• the main benefit is earlier and more precise failure on an invalid mixed representation
• the main downside, kept in question here, is that it makes transaction conversion fallible
• related follow-up question:
  • should the same policy apply to output covenant binding as another version-incompatible field combination?
  • or should that remain outside the conversion layer?