Re-translate LaunchPlan fixed inputs with remote context on registration

[dansola]

Why are the changes needed?

When a LaunchPlan is created with a StructuredDataset or FlyteFile as a fixed_input, flytekit eagerly serializes those inputs to Flyte literals at LaunchPlan.create() time using the local FlyteContext. At that point, the FileAccessProvider points to a local /tmp directory, so any file or dataset upload goes there instead of remote storage. When the launch plan is later registered, the serialized literal contains a /tmp path that the remote Flyte cluster cannot access.

What changes were proposed in this pull request?

• LaunchPlan.__init__ now stores _raw_fixed_inputs, the original Python native values passed as fixed_inputs before they are serialized to a LiteralMap.
• LaunchPlan.create() populates _raw_fixed_inputs alongside the existing _saved_inputs.
• FlyteRemote.register_launch_plan() now re-translates raw_fixed_inputs using self.context, which has a FileAccessProvider configured for remote storage. This overwrites the stale local literals before the launch plan is serialized and sent to Flyte Admin.

How was this patch tested?

Added test_register_launch_plan_retranslates_fixed_inputs_with_remote_context in tests/flytekit/unit/remote/test_remote.py. The test creates a LaunchPlan with a FlyteFile fixed input and asserts that translate_inputs_to_literals is called with the remote context (rr.context) during register_launch_plan. The test was also verified to fail against the pre-fix code, confirming it catches the regression.