Hotfix: bump sp1 version in validating public inputs example

Description

Fixes the version in the validating public input example.

To Test

• To test this on the holesky network you will need a holesky eth wallet. For reference follow the example readme here.
• cd examples/validating-public-input/
• In examples/validating-public-input/contracts create a .env with the parameters for the holesky testnet.

For Sp1:

• Generate the sp1 proof: make generate_sp1_fibonacci_proof
• Send the proof to testnet: make submit_fibonacci_sp1_proof KEYSTORE_PATH=<LOCAL_KEYSTORE_PATH>
• Deploy the validating contract make deploy_fibonacci_validator KEYSTORE_PATH=<LOCAL_KEYSTORE_PATH>
• make verify_sp1_batch_inclusion FIBONACCI_VALIDATOR_ADDRESS=<FIBONACCI_VALIDATOR_ADDRESS> DATA_FILE_NAME=<DATA_FILE_NAME>. Where FIBONACCI_VALIDATOR_ADDRESS is the address of the deployed validator contract and DATA_FILE_NAME the name of the file where the aligned verification data was saved (including the extension .json).
• If successful you should see:

...
root                    <ROOT_HASH>
status                  1 (success)
transactionHash         <TX_HASH>
...

For Risc0:

• Generate the risc0 proof: make generate_risc0_fibonacci_proof
• Send the proof to testnet: make submit_fibonacci_risc0_proof KEYSTORE_PATH=<LOCAL_KEYSTORE_PATH>
• Deploy the validating contract make deploy_fibonacci_validator KEYSTORE_PATH=<LOCAL_KEYSTORE_PATH>
• make verify_risc0_batch_inclusion FIBONACCI_VALIDATOR_ADDRESS=<FIBONACCI_VALIDATOR_ADDRESS> DATA_FILE_NAME=<DATA_FILE_NAME>. Where FIBONACCI_VALIDATOR_ADDRESS is the address of the deployed validator contract and DATA_FILE_NAME the name of the file where the aligned verification data was saved (including the extension .json).
• If successful you should see:

...
root                    <ROOT_HASH>
status                  1 (success)
transactionHash         <TX_HASH>
...

Type of change

Please delete options that are not relevant.

• Hot Fix

Checklist

• “Hotfix” to testnet, everything else to staging
• Linked to Github Issue
• This change depends on code or research by an external entity
  • Acknowledgements were updated to give credit
• Unit tests added
• This change requires new documentation.
  • Documentation has been added/updated.
• This change is an Optimization
  • Benchmarks added/run
• Has a known issue
  • Link to the open issue addressing it
• If your PR changes the Operator compatibility (Ex: Upgrade prover versions)
  • This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
  • This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible