Support TaskInstanceHistory in log handlers

[sunank200]

This change fixes the log API to fully support TaskInstanceHistory by adding an id alias, a get_dagrun() helper to TaskInstanceHistory. This also updates FileTaskHandler to recognise history objects, and fixes the missing try_number filter in the FastAPI route so that retry task logs can be fetched correctly.

I have tested it by updating log_filename_template = dag_id={{ ti.id }}/run_id={{ ti.run_id }}/task_id={{ ti.task_id }}/{%% if ti.map_index >= 0 %%}map_index={{ ti.map_index }}/{%% endif %%}attempt={{ try_number|default(ti.try_number) }}.log and ran the task, then cleared the task instance and checked the log.

closes: #51525

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[dstandish]

looks ok to me

[jason810496]

Related to #50175

The #50175 try to fix on FastAPI side instead of FileTaskHandler, but introduce other error ( #50175 (comment) ).

[sunank200]

Related to #50175

The #50175 try to fix on FastAPI side instead of FileTaskHandler, but introduce other error ( #50175 (comment) ).

I have tested for the error mentioned in the issue. It works fine with this change.

[jedcunningham]

Overall, looks good. Are other task handlers impacted by these typing changes? If so, probably can be addressed in a follow up as they'd be in providers...

[jason810496]

Overall, looks good. Are other task handlers impacted by these typing changes? If so, probably can be addressed in a follow up as they'd be in providers...

IMO, we don't need to adapt TIH type hit for other provider-based task handlers, as most of them already adapted to RemoteIO interface ( which use RuntimeTaskInstanceProtocol as type annotation )

[sunank200]

Overall, looks good. Are other task handlers impacted by these typing changes? If so, probably can be addressed in a follow up as they'd be in providers...

IMO, we don't need to adapt TIH type hit for other provider-based task handlers, as most of them already adapted to RemoteIO interface ( which use RuntimeTaskInstanceProtocol as type annotation )

I can do a follow-up PR if required.