[Improvement] [API] Improve the task instance large-field optimization to align with the WorkflowInstance approach

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and found no similar feature requirement.

### Description

**Background**

PR #18442 optimized TaskInstanceMapper by introducing lightweight projections (listSql/listSqlV2) that omit the heavy text columns task_params and var_pool from list queries.
The intent is correct, but the initial implementation is too minimal compared with the later workflow-instance optimization (#18444):

1.Silent API contract change. The list APIs still serialize the full TaskInstance entity, so taskParams/varPool now silently become null in responses — with no incompatible.md entry and no VO-level documentation, consumers cannot tell this is intentional.

2.Projection applied to non-list queries. Methods whose names do not imply "list" were also switched to the light projection:
queryByInstanceIdAndCode is effectively a single-row/detail lookup, yet now omits task_params;
findLastTaskInstances/findLastTaskInstance are consumed by the master dependency calculation (DependentExecute → queryLastTaskInstanceListIntervalInWorkflowInstance), an internal execution path that may later need the full row.

3.No dedicated DTO/VO. Results are still mapped into the full TaskInstance entity, so the "list contract" cannot be expressed at the type level, and columns that the list UI never needs (e.g. execute_path, log_path, app_link) still leak through.

4.No shape-level tests. TaskInstanceMapperTest only asserts non-null / row counts; nothing verifies which fields a list query must not return.

### Are you willing to submit a PR?

- [x] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)