fix: merge LaunchPlan security context per field on registration

[1fanwang]

Why are the changes needed?

Registering a launch plan that declares secrets (or tokens) while passing registration Options that only set a service account silently drops the secrets. get_serializable_launch_plan does options.security_context or entity.security_context — a wholesale replace — so any non-empty options context wipes whatever the launch plan authored.

What changes were proposed in this pull request?

Merge the two security contexts per field instead of replacing wholesale: options win field-by-field (run_as, secrets, tokens), so a service-account-only override stops clobbering authored secrets.

How was this patch tested?

test_get_serializable_launch_plan drives the same path. Also end-to-end against a real flyteadmin (flyte demo): register the secrets launch plan with service-account-only options and read it back — before, secrets returns None (dropped); after, it's preserved alongside the overridden service account.

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

[machichima]

nit: not a blocker, just wondering if a user explicitly sets secrets=[] or tokens=[] in options to clear the entity value, we'll ignore them here and use the one from entity. Have you observed any usage of setting them as empty list?

[1fanwang]

Good point — right now the or treats an explicit empty list the same as "unset", so options.secrets=[]/tokens=[] can't clear an authored list; the launch-plan value wins. I haven't seen []-to-clear used in practice (registration options have been additive in what I've hit — service account, labels), so I kept the simpler or. If you'd rather honor an explicit empty list as "clear", I can switch to an is not None check per field — happy to do whichever you prefer.

[machichima]

Thanks, we can keep it simpler for now

[machichima]

LGTM! Thank you. Please rebase/merge master for the CI fix