feat(mysql-dual-conn): add endpoint to trigger COM_STMT_RESET

[khareyash05]

Description

Adds GET /api/oms/stmt-reset/{n} to mysql-dual-conn that re-executes a
server-side prepared statement n times on the same JDBC connection.
Also updates the OMS JDBC URL with
useServerPrepStmts=true&cachePrepStmts=true&useCursorFetch=true so MySQL
Connector/J 8.x emits COM_STMT_RESET between re-executions.

This lets keploy's existing java_linux CI pipeline exercise the
COM_STMT_RESET synthetic-OK fallback added in keploy/keploy#4217 without
needing to wire a brand new sample app into keploy's workflows. The
existing dual-handshake test path is unaffected — the Camunda pool keeps
the original JDBC URL, and the new endpoint is purely additive.

Related: keploy/keploy#4217 (the match.go fix this endpoint exercises).
A separate PR will be opened against keploy/keploy to add a
curl http://localhost:8080/api/oms/stmt-reset/5 line into
.github/workflows/test_workflow_scripts/java/mysql_dual_conn/java-linux.sh.

Fixes # (n/a)

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

cd mysql-dual-conn
docker compose up -d                           # MySQL 8 with myntra_oms + camunda DBs
mvn -B -DskipTests package                     # produces target/mysql-dual-conn-0.0.1-SNAPSHOT.jar

# Record
keploy record -c "java -jar target/mysql-dual-conn-0.0.1-SNAPSHOT.jar"

# In another shell
curl http://localhost:8080/api/query-both
curl http://localhost:8080/api/oms/stmt-reset/5

# Replay
keploy test -c "java -jar target/mysql-dual-conn-0.0.1-SNAPSHOT.jar" --delay 20

The replay log shows the COM_STMT_RESET debug line (stmt id) from
keploy/keploy#4217, and the run completes without
CJCommunicationsException / Socket is closed.

Additional Context

• The OMS pool was chosen over the Camunda pool deliberately so the
  existing dual-handshake assertions stay unchanged.
• The endpoint uses JdbcTemplate.execute(ConnectionCallback) to pin all
  n executions to one physical connection; otherwise HikariCP could
  hand out a fresh connection per executeQuery() and the
  COM_STMT_RESET packet would never be emitted.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have signed the commit message (--signoff)