feat: detect host operating system at startup and provide platform-specific guidance

docs/meeting-assistant-configuration.md

@@ -382,7 +382,8 @@ The top-level `Logging` section is standard ASP.NET Core logging configuration a
 Independently from stdout and stderr redirection, Meeting Assistant writes an application-owned log under:
 
 ```text
-%TEMP%\MeetingAssistant\Logs\meeting-assistant.log
+Windows: %TEMP%\MeetingAssistant\Logs\meeting-assistant.log
+macOS:   $TMPDIR/MeetingAssistant/Logs/meeting-assistant.log
 ```
 
 On startup it rotates the previous current file to `meeting-assistant.log.1` and keeps up to `.4`. The tray-launched assistant reads and searches these current and rotated files. If another app instance or test host still has the file open, rotation is skipped and logging appends to the current file so startup is not blocked.

docs/meeting-workflow-engine.md

@@ -24,6 +24,8 @@ If the configured path is empty, missing, or points to a blank file, the workflo
 
 The tray menu includes `Open agent`, which opens the `Meeting Summary Agent` chat window for this configured rules file, the local speaker identity database, appsettings configuration, and application logs. The assistant uses the summarizer agent configuration by default and can be overridden through `MeetingAssistant:WorkflowRulesEditor`.
 
+Meeting Assistant detects the host operating system once during application startup and appends that context to the interactive agent prompt. Windows hosts receive PowerShell, Windows-path, Windows-service, and Task Manager guidance. macOS hosts receive zsh, POSIX-path, launchd/LaunchAgent, and Activity Monitor guidance. Other hosts receive neutral portable guidance. The platform context remains present when `WorkflowRulesEditor:InitialPrompt` is configured, and it does not imply that unavailable platform integrations have been implemented.
+
 ```json
 {
   "MeetingAssistant": {