feat: add template generate lightning-out command (Option A)

[akashdhake]

feat: add template generate lightning-out command

Repo: salesforcecli/plugin-templates
State: DRAFT — LO 2.0 (release 266) scaffolding spike POC

Stacked as two PRs:

• PR 1 (Option A): lo2/lightning-out (base: main @ d64a80b, commit 6140d24) — the command, generate-only, always warns on the REPLACE risk. Depends on salesforcedx-templates PR 1 (lo2/lightning-out).
• PR 2 (Option B): lo2/lightning-out-merge (base: lo2/lightning-out, commit 079129f) — adds only --merge-iframe/--target-org + retrieveIframeEntries (5-file delta). Depends on salesforcedx-templates PR 2 (lo2/lightning-out-merge). Review after PR 1.

What

Adds the sf template generate lightning-out command. It reads a JSON definition
file and delegates to the @salesforce/templates LightningOut generator to
scaffold a Lightning Out 2.0 app's seven metadata artifacts. Generate-only — it
does not deploy.

Flags

Flag	Purpose
--definition-file (-f)	app definition: name, runtime, components, hostDomains, eca
--output-dir (-d)	output directory
--force	overwrite existing files (Option A guardrail is on by default)
--merge-iframe	Option B: preserve the org's existing Trusted Domains list
--target-org	org to retrieve the current iframe list from (required by --merge-iframe)

Option A vs Option B (the IframeWhiteListUrlSettings risk)

Deploying IframeWhiteListUrlSettings REPLACES the org's entire "Trusted Domains for
Inline Frames" list across all IFrame Types.

• Default (Option A): the command emits a warning that the generated file will
  REPLACE the org's list on deploy, and the generator refuses to silently overwrite
  an existing file without --force.
• --merge-iframe --target-org <org> (Option B): retrieveIframeEntries reads
  the org's current IframeWhiteListUrlSettings via the Metadata API and passes
  every entry (context preserved) to the generator, so the deploy ADDS this app's
  domains rather than wiping the list.

Files

• src/commands/template/generate/lightning-out/index.ts — the command
• src/utils/lightningOutIframe.ts — retrieveIframeEntries helper
• messages/lightningOut.md
• test/commands/template/generate/lightning-out/index.nut.ts — 11 NUTs
• test/utils/lightningOutIframe.test.ts — 6 unit tests

Testing

• 11 NUTs (all artifacts, rendering, warning, Option A guardrail + force, all failure
  modes) + 6 unit tests (read() scalar/array normalization, context preservation
  across IFrame Types, url filtering) — 17 passing. Compile + lint clean.
• Live-org end-to-end (Option B): starting org iframe list = 1 entry
  (test-domain-x.example.com) → --merge-iframe --target-org emptyOrg retrieved 1
  and generated a 3-entry file → deployed successfully → re-retrieved: all 3
  survived (pre-existing entry + 2 app domains). Proves the merge is additive
  against a REPLACE-type deploy. The live deploy also caught a real bug (a -- inside
  the WARNING XML comment is invalid XML and was rejected by the platform) — now fixed
  and regression-tested in the generator repo.

[salesforce-cla]

Thanks for the contribution! Unfortunately we can't verify the commit author(s): adhake <a***@s***.com>. One possible solution is to add that email to your GitHub account. Alternatively you can change your commits to another email and force push the change. After getting your commits associated with your GitHub account, refresh the status of this Pull Request.