I believe it's the opposite. If you remove a field, the consumer tests will fail (assuming they were actually using that field). If you add a new field, but don't change the behaviour of existing fields, then the consumer is not affected, hence their contract tests should not fail.
I wonder though, if the contract tests can identify fields unused by the consumer(s), so that the provider can potentially remove them. My hunch is that this should be handled by conventional code coverage, not by contract tests per se.
Which leads to a potential resolution to your question. If the goal is to ensure in a somewhat automated way that the consumer uses the new field, then one possibility is, the code coverage in their tests will drop if the field is not used.
However, this is perhaps better communicated by conventional means, that is, talking to the consumer's developers. (I'm assuming that was already done, and the idea described in this question is a supplement to that.)