Honor prepared_statements: false in perform_query and _exec_insert

[yahonda]

Summary

OracleEnhanced::DatabaseStatements#perform_query and #_exec_insert previously took the same branch whenever binds were present — cache the cursor in @statements[sql], bind values, execute — regardless of the connection's prepared_statements flag. As a result, even connections configured with prepared_statements: false (or running inside an unprepared_statement do ... end block) had their bind-ful queries prepared and cached client-side.

This PR adds a prepared_statements? branch on the bind-present path so that prepared_statements: false connections prepare-and-execute one-shot (no cache), matching PostgreSQL's exec_params path and the spirit of the AR setting.

if prepared_statements?
  @statements[sql] ||= raw_connection.prepare(sql)   # cached, reused
  cursor = @statements[sql]
  cached = true
else
  cursor = raw_connection.prepare(sql)               # one-shot
end
cursor.bind_params(type_casted_binds)

cursor.close unless cached at the tail already releases the one-shot cursor. The Oracle DB shared pool may still recognize the SQL text and reuse its parsed plan, but no client-side handle is retained.

Why

• Honor the user's intent. A connection configured with prepared_statements: false was, until now, still keeping prepared cursor handles for every distinct bind-ful SQL text. That's inconsistent with the AR contract.
• Make the cost of bound dictionary queries (Bind literals in dictionary queries #2629) visible to prepared_statements: false callers. Without this branch, the cached client-side handle was masking the per-call parsing the user explicitly opted into.
• Match PG/MySQL behavior. PostgreSQL routes intent.prepare false through exec_params (parameterized but not prepared). Oracle now has the analogous path through OCI8 / JDBC's prepare-bind-exec-close lifecycle.

Backend coverage

OCI8 and JDBC both expose the same Cursor abstraction with prepare(sql) → bind_params → exec → close. The branch lives in the shared database_statements.rb, so the change applies uniformly to both backends with no per-backend duplication.

Spec adjustments

The two existing statement-pool specs in oracle_enhanced_adapter_spec.rb asserted that bind-ful queries grow @statements. That's now specific to prepared_statements: true:

• should clear older cursors when statement limit is reached — gated on @conn.prepared_statements?
• should cache UPDATE statements with bind variables — gated on @conn.prepared_statements?

Plus a new symmetric spec for the new path:

• should not cache UPDATE statements with bind variables when prepared_statements is false — asserts the pool size doesn't grow.

Test plan

• CI green (default prepared_statements: true workflow)
• Daily master test_prepared_statements_false workflow green after merge
• Local: full suite passes in both modes (verified):
  • prepared_statements: true → 609 examples, 0 failures, 7 pending
  • prepared_statements: false → 609 examples, 0 failures, 8 pending (one extra pending is the now-skipped prepared_statements: true-only assertion)