[light] Reword apply-fn comments to describe codegen failure mode

esphome/components/light/automation.h

@@ -37,8 +37,11 @@ template<bool HasTransitionLength, typename... Ts> class ToggleAction : public A
 // Trigger args are forwarded to the apply function so user lambdas
 // (e.g. `brightness: !lambda "return x;"`) keep working.
 //
-// Ts... must be forwarded by-value: `const T &` is ill-formed when T is
-// already a reference type (some triggers pass `std::string &`).
+// Trigger args are forwarded as `Ts...`. The previous `const Ts &...`
+// form caused codegen to emit `const T &` for each arg in the apply
+// lambda's parameter list, which is invalid C++ source text when T is
+// already a reference (e.g. `const std::string & &` for triggers that
+// pass `std::string &`).
 template<typename... Ts> class LightControlAction : public Action<Ts...> {
  public:
   using ApplyFn = void (*)(LightState *, LightCall &, Ts...);

esphome/components/light/automation.py

@@ -230,8 +230,11 @@ async def light_control_to_code(config, action_id, template_arg, args):
                 f"call.set_effect(static_cast<uint32_t>({_resolve_effect_index(config)}));"
             )
 
-    # Match LightControlAction::ApplyFn signature: trigger args forwarded
-    # by-value as Ts...
+    # Forward trigger args as Ts... so each (type, name) pair passes through
+    # unchanged. Wrapping in `const &` here would emit invalid C++ source
+    # for trigger types that already carry a reference (e.g. `std::string &`)
+    # and fails on plain Python types (`float`/`bool`) which have no
+    # `.operator()` method.
     apply_args = [
         (LightState.operator("ptr"), "parent"),
         (LightCall.operator("ref"), "call"),