fix: preserve trigger options field during automation import/export

[davhparry]

Description

Adds Options field to all trigger structs so LCM action configuration (actionId, chooseTargetAtRuntime) is no longer dropped during export/import. Also adds a default passthrough in transformTrigger and updateTriggers so unknown trigger types are preserved rather than erroring or being silently dropped.

Fixes #177

Type of Change

• Bug fix
• New feature
• Documentation
• Refactor
• Chore

Changes Made

• Updates ManualTrigger.MarshalJSON to include Options when present
• Replaces the error-returning default case in transformTrigger (export path) with a passthrough that preserves unknown trigger types as raw JSON
• Adds the same passthrough default case to updateTriggers (import path) so unknown trigger types are no longer silently dropped

Testing

• [ x] Export an automation with a resource_models componentType that has an LCM action trigger — verify options (actionId, chooseTargetAtRuntime) appears in the exported JSON
• [x ] Re-import that exported file — verify the automation imports successfully with the trigger options intact
• [x ] Verify existing automation export/import (workflow, compliance_plan types) still works correctly
• [x ] Run make test — all tests pass

Checklist

• [ x] Code follows the project's style guidelines
• [ x] Self-review of code has been performed
• [ x] Code has been commented where necessary
• [ x] Tested with make setup or relevant profile
• [ x] Commits follow conventional format (type: subject)
• [ x] No secrets or credentials committed
• [ x] Documentation has been updated accordingly
• [ x] PR has been labeled appropriately (enhancement, bug, documentation, refactor, chore)

[wcollins]

Minor notes - (not blocking, but good idea for future change)

• Naming mismatch: transformationsImportWithTagsSuccess points at a fixture named export.with-tags.json, and it's placed via an import test because TransformationService has no Export method. Functionally fine - import is where the decode happens - but the fixture name will confuse the next reader. Could be renamed in a follow-up.
• Small behavior change: hand-authored asset files containing "tags": ["some-string"] used to import; now they'll fail to unmarshal. Real platform exports always use objects, and workflows already made this exact trade in fix: add tags support to workflow export and import #204, so this is acceptable and consistent - Adding this into git just in case it comes up in the futrue.
• Residual looseness elsewhere: templates.go:31 still uses Tags []interface{}, dodging the same problem untyped. Out of scope here, but a candidate for the same treatment later.
• One untested assumption: the fix is verified for export/import; if some platform version's GET/list endpoints return tags as ID strings instead of objects, those would now fail to decode. The workflows and golden-config precedents suggest the platform always returns objects, so I'd rate this low risk.