Strengthen workflow automation diagnostics

docs/meeting-workflow-engine.md

@@ -22,6 +22,16 @@ The rules file path is configured through `MeetingAssistant:Automation:RulesPath
 
 If the configured path is empty, missing, or points to a blank file, the workflow engine does nothing.
 
+`POST /diagnostics/workflow/reload` reloads application configuration without restarting the process. Use it after changing workflow automation configuration such as `MeetingAssistant:Automation:RulesPath`. The endpoint returns the currently bound rules path:
+
+```json
+{
+  "rulesPath": "meeting-rules.local.yaml"
+}
+```
+
+The YAML rules file itself is read for every workflow event, so changing the contents of the same rules file does not require this endpoint. Use the endpoint when the application configuration changes, for example when pointing `RulesPath` to a different YAML file. A meeting run that already captured its options may continue with those options; future runs and future configuration reads use the reloaded configuration.
+
 ## Execution Model
 
 The engine runs when `MeetingRecordingCoordinator` emits a meeting workflow event:
@@ -291,6 +301,7 @@ Core files:
 - `MeetingAssistant/Workflow/FileMeetingWorkflowRulesProvider.cs`
 - `MeetingAssistant/Recording/MeetingRecordingCoordinator.cs`
 - `MeetingAssistant.Tests/MeetingWorkflowEngineTests.cs`
+- `MeetingAssistant.Tests/MeetingWorkflowDiagnosticEndpointTests.cs`
 
 When extending the workflow engine:
 
@@ -299,4 +310,3 @@ When extending the workflow engine:
 3. Keep the supported trigger, condition, template model, and step lists in this document current.
 4. Keep `README.md` as the short operational overview and link back here for details.
 5. Keep the local rules file ignored by git; do not commit personal automation rules.
-