feat: promote a trigger to a task version

[dansola]

Overview

Adds promotion for triggers: point a trigger at a deployed task version and pin it there, so deploying new versions registers code without moving what the trigger runs. Needs TriggerService.PromoteTrigger from the companion flyteorg/flyte PR.

@env.task(triggers=[flyte.Trigger(name="prod")])   # declares the entrypoint, no version in code
async def ingest(payload: str) -> str: ...

flyte deploy --version v1.6.0 ingest.py env                          # registers v1.6.0; doesn't move a promoted prod
flyte update trigger prod event_driven.ingest --to-version v1.6.0     # prod: v1.4.0 -> v1.6.0
flyte update trigger prod event_driven.ingest --to-version v1.4.0     # roll back, nothing rebuilt

A trigger that was never promoted follows every deploy, as today. The caller launches by trigger name and never names a version:

prod = flyte.remote.TriggerDetails.get(name="prod", task_name="event_driven.ingest")
flyte.run(prod, payload=event["detail"])

What changed

• flyte update trigger gains --to-version. --activate/--deactivate is now optional; at least one of the two is required, and both can be passed together. Output: Trigger prod: v1.4.0 -> v1.6.0.
• flyte.remote.Trigger.promote(name, task_name, task_version) returns (TriggerDetails, previous_task_version).
• TriggerDetails.task_version and TriggerDetails.task_version_pinned.
• The promote_trigger protocol method uses string annotations, so task images that install a released flyteidl2 without the new messages still import the client.

How this was tested

• tests/cli/test_update_trigger.py: promote, promote to the current version, activate only, and neither flag (usage error). ruff clean.
• End to end against a local backend with promotion, through the CLI: deploy r1 and r2 (unpromoted trigger follows to r2), promote to r1 and launch by name with a payload (runs r1), deploy r3 and r4 (still r1), promote to r4 (runs r4), roll back to r1 (runs r1), promote to a never-deployed version (rejected, unchanged).

Dependency

Needs a flyteidl2 release with PromoteTrigger; pyproject.toml pins flyteidl2==2.0.49. Merge after the proto PR lands and the pin is bumped.