Fixing `invalid_tx_code`

PR #686 was merged after I had the opportunity to discuss the following scenario:

Scenario:

• Wallet 1.0 expects invalid_grant for an invalid transaction code (before the PR was merged)
• Wallet 1.1 expects invalid_tx_code for an invalid transaction code
• Issuer 1.0 returns invalid_grant for an invalid transaction code (before the PR was merged)
• Issuer 1.1 returns invalid_tx_code for an invalid transaction code

Assuming that mixed Wallet and Issuer versions need to interoperate, should we introduce additional considerations for handling invalid_tx_code? I do see interoperability issues in some scenarios, and I no longer recall why they were considered acceptable. I created the PR based on these assumptions but I feel we should at least document them.

Furthermore, should we revert the text in the 1.0 errata to the original wording, where invalid_grant was returned in case the transaction code was invalid?

Additionally, @paulbastian raised a point that we would also need an additional error code for here https://github.com/openid/OpenID4VCI/pull/686#issuecomment-4294623956:

error code can be also used when correct tx_code was entered too many times. PR might follow.

@paulbastian @c2bo @jogu @fkj @javereec @Sakurann

Review PR #686 and the 1.0 errata wording, then trace the mixed Wallet and Issuer version scenarios described here. Determine the expected handling for invalid transaction codes and repeated correct-code attempts, and document or revise the protocol behavior once the interoperability decision is settled.