Exercise 3: A when: False Task's Effect on Its Own notify — Possible Solution
====================================================================

Explanation:

Per the chapter's own warn-box, a task's when: condition is evaluated
first, and if it evaluates to false, the ENTIRE task is skipped --
Ansible doesn't run the module, doesn't copy anything, and reports the
task as "skipped" rather than "ok" or "changed" for that host. Because
the task never actually executes at all on a host where
feature_flag_enabled is false, it also never reaches the point where
it would report changed=true and trigger its own notify: line -- the
notify simply never fires, on this host, for this run.

The direct consequence: the "restart myapp" handler is NOT triggered
by this task on that host, and if nothing else in the play also
notifies that same handler, myapp is never restarted at all during
this run, on this specific host. This is exactly the gotcha the
chapter warns about -- the notify: line is still sitting right there
in the playbook file, visually implying "this will restart myapp when
the config changes," but a skipped task's notify is just as skipped as
everything else about that task. Someone debugging "why didn't myapp
restart" on this host would need to specifically check whether the
when: condition itself was ever true in the first place, not just
assume the notify mechanism failed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the exact mechanism (when: false skips the whole task
before it could ever report changed or trigger notify) rather than
just stating the conclusion, and explicitly connects the scenario back
to the chapter's own named gotcha about skipped tasks and their
notify lines.