…urrent CI jobs

`_unique_table_name` derived the table name purely from the test node id,
so two CI runs racing on the same warehouse + catalog (e.g. PR + push to
main landing within seconds, as happened in run 26410038645) would both
target `peco.default.mst_pysql_<test_name>` and step on each other's
CREATE / DROP / DML. This caused the three "flaky" failures we kept
seeing in `test_transactions.py`:

  - test_multi_table_commit       → TRANSACTION_ROLLBACK_REQUIRED_AFTER_ABORT
  - test_executemany_rollback_in_txn → TABLE_OR_VIEW_NOT_FOUND
  - test_write_conflict_single_table → TABLE_OR_VIEW_ALREADY_EXISTS

The companion helper `_unique_table_name_raw` already appended a uuid4
suffix for exactly this reason; the fixture helper was an oversight from
#775. Add the same suffix here, reserving room so the result still fits
in the 80-char cap.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>

…ation

While verifying the transactions fix, a second flake surfaced — the same
cross-CI race pattern, this time on a UC Volume file path:

  tests/e2e/test_driver.py::TestPySQLCoreSuite::
    test_uc_volume_put_fails_if_file_exists_and_overwrite_not_set
  → Failed: DID NOT RAISE <class 'databricks.sql.exc.ServerOperationError'>

Two tests in `tests/e2e/common/uc_volume_tests.py` PUT/GET/REMOVE against
the hardcoded path `/Volumes/{catalog}/{schema}/e2etests/file1.csv`. When
two CI runs overlap (as happened on this PR after the force-push for DCO
sign-off), one run's REMOVE deletes the other run's file between its two
PUTs, so the expected `FILE_IN_STAGING_PATH_ALREADY_EXISTS` never fires.

Suffix the volume path with `uuid4().hex[:8]` in the two affected tests
(test_uc_volume_life_cycle and test_uc_volume_put_fails_if_file_exists_
and_overwrite_not_set). The other UC Volume tests that reference the same
path are exercising client-side / server-parse failure paths that never
touch the file — leaving those alone keeps the diff focused.

Also add a `concurrency` block to the E2E workflow:

  - On pull_request, cancel-in-progress: a new push / force-push on a PR
    cancels the previous run on that ref. Eliminates the entire class of
    "force-pushed during CI → two runs racing on shared warehouse state"
    failures.
  - On push to main, runs are NOT cancelled — each merge commit keeps its
    own clean CI signal so a regression on commit N can't be hidden by
    commit N+1 landing seconds later. Concurrent main runs can still
    collide on shared state, but the uuid-suffix conventions in the e2e
    tests are what keep that isolated.

Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>