[BugFix] Fix JDBC kill task not cleaning up DDL state (#5320)

[zhang-arvin]

What is the purpose of the change

Fix JDBC engine kill task not cleaning up DDL state. When a DDL statement (CREATE TABLE/VIEW) is being executed and the task is killed mid-execution, the partially created objects should be cleaned up by issuing DROP IF EXISTS statements.

Brief change log

• Store the executing SQL code in executeLine using taskCodeMap
• When killTask is called, parse the original SQL for DDL statements (CREATE TABLE/VIEW)
• Generate corresponding DROP IF EXISTS statements to clean up partially created objects
• Execute cleanup DDL using the existing connection before killing the task

Verifying this change

This change ensures that when a user kills a DDL task, any partially created tables or views are properly cleaned up.

Does this pull request potentially affect one of the following parts:

• Dependencies (no)
• Anything that affects deployment (no)
• The Core framework (no)

[zhang-arvin]

Base-branch note: the failing checks are not caused by this PR.

All of sql-check, spotless-check, third-party-dependencies-check and build-backend fail on files that this PR does not touch, and they fail identically on the other open PRs from the same branch point. The failures come from master itself:

• sql-check: linkis-dist/package/db/linkis_dml.sql:670 — ERROR 1136: Column count doesn't match value count at row 11 (the Oracle datasource INSERT), introduced by [SECURITY] Block JDBC URL-option injection via DB2 instance field #5450.
• spotless-check: linkis-commons/linkis-common/.../TicketCipher.java format violation, from the DES→AES change in [SECURITY] Upgrade session ticket cipher from DES to AES-256-GCM #5460.
• build-backend / third-party-dependencies-check: linkis-commons/linkis-module/.../ServerConfiguration.scala:80 and SecurityFilter.scala:158 — not found: value CRYPT_KEY_INSECURE / not found: value CommonVars, from [SECURITY] Remove hardcoded default wds.linkis.crypt.key, fail-closed on insecure values #5456.

None of these files appears in this PR's diff, so there is nothing on this PR to fix here; it will go green once master is repaired. This PR stays on the master baseline problem until that lands.

This comment was generated by an AI agent (Hermes Agent).