Krikri::StaticImportRoleUndefinedError

Real Ansible's import_tasks:/import_role: are genuinely STATIC, parse-time constructs - the templated file/role path may reference vars/vars_files/extra-vars only, never facts (which don't exist yet at parse time) or inventory sources. Referencing one anyway is a FATAL playbook-load error ("Error when evaluating variable in import path... Static imports cannot use variables from facts... '' is undefined", rc=4, zero tasks run) - not a per-task skip. This engine already resolves a templated import_tasks: path using known_vars (role defaults/vars/invocation vars only, deliberately never merged with facts - see RoleLoader#load_role's own "Known at parse time, before facts gathering" comment), so a fact-only reference here simply resolves to nothing - previously #try_parse_import_tasks's non-strict substitution silently rendered that as the "undefined" sentinel ("setup-undefined.yml"), which then just failed to resolve as a path and was swallowed by #parse_tasks's own generic per-task rescue into a soft "Warning: ... not found" - the play continued with the import task simply missing, ok=0 and exit 0, not real Ansible's hard rc=4 refusal. Verified directly against real ansible-playbook with a minimal repro (import_tasks: "setup-{{ ansible_os_family }}.yml", no default/vars value for ansible_os_family): identical message shape, 'ansible_os_family' is undefined. Bypasses #parse_tasks's generic per-task rescue (same mechanism as RemovedActionError above) so it propagates all the way to krikri-playbook.cr's own top-level "Error parsing playbook:" handler instead of being swallowed as a soft warning. import_role:'s NAME failing to resolve is reported by real Ansible as a plain undefined-variable error with exit code 1, NOT the parser-error 4 it uses for an import_tasks: PATH (verified against ansible-core 2.19.4). Separate class so krikri-playbook.cr can honor that difference.