ci: Add ORA_TZFILE workaround to ruby_head

[yahonda]

Summary

Mirror PR #2734's ORA_TZFILE workaround into .github/workflows/ruby_head.yml.

ruby_head.yml runs the same Oracle Instant Client (rolling-latest, currently 23.26.2.0.0) against the same gvenzl/oracle-free:latest server image (currently 23.26.1.0.0) used by test.yml. Without the workaround, every CRuby row of the head/debug/asan matrix produces ORA-01805: possible error in date/time operation on the four TIMESTAMP WITH TIME ZONE examples in spec/active_record/oracle_enhanced/type/timestamp_spec.rb — exactly the failure mode #2734 was opened to fix.

Change

Insert the same step that test.yml already runs between "Create database user" and "Bundle install":

- name: Force client TZ data to match server (ORA_TZFILE workaround)
  run: |
    ORACLE_CONTAINER=$(docker ps --filter "ancestor=gvenzl/oracle-free" -q)
    SRC=$(docker exec "$ORACLE_CONTAINER" bash -c 'ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat 2>/dev/null | head -1')
    ...
    echo "ORA_TZFILE=$DST_DIR/$(basename "$SRC")" >> $GITHUB_ENV

Why only ruby_head.yml?

Workflow	Image	Already has workaround?	Needs change?
test.yml	gvenzl/oracle-free	Yes (#2734)	No
test_prepared_statements_false.yml	gvenzl/oracle-free	Yes	No
ruby_head.yml	gvenzl/oracle-free	No	Yes
jruby_head.yml	gvenzl/oracle-free	No	No — JDBC ships its own TZ data and ignores Instant Client's
test_11g.yml	gvenzl/oracle-xe:11	Yes (v14 variant)	No
test_11g_ojdbc11.yml	gvenzl/oracle-xe:11	Yes (v14 variant)	No

Test plan

• Trigger ruby_head via workflow_dispatch on yahonda/oracle-enhanced and confirm the matrix passes, in particular spec/active_record/oracle_enhanced/type/timestamp_spec.rb.
• Same on rsim/oracle-enhanced once merged (next nightly cron at 00:00 UTC).

🤖 Generated with Claude Code