Refactor MQTT course and bound backend message processing

Move lesson source into the teaching structure, align the course path with the learner's Go and DevOps experience, and add the interactive lesson guides. Add advanced DevOps lifecycle study as a separate section.

Bound MQTT message work and drain accepted jobs during shutdown; align the backend implementation with the revised course through Section 6.

teaching/NOTES.md

@@ -0,0 +1,12 @@
+# Teaching Notes
+
+- Learner's stated mission: implement and maintain a Go backend with MQTT 5 and Mosquitto for vending-device telemetry, logs, status, commands, and updates.
+- Learner initially reported studying through Section 5, then reported finishing through Lesson 5A and requested learner-facing lessons through the end of the Section 18 course plan. HTML guides now cover Lessons 9–18; Lesson 11B is optional. Lesson 6–8 HTML guides already existed.
+- Learner is a mid-level Go backend engineer with four years of experience and is confident in Go syntax and core language concepts. Do not teach Go basics or recheck Go proficiency; focus Go explanations on design choices and language behavior that materially affects ownership, concurrency, cancellation, error handling, or API shape.
+- Learner has junior-level DevOps experience. Advanced delivery and operations lifecycle practices belong in the separate Section 17A lesson, introduced after the operations/diagnostics section and before backend handover; keep the main MQTT implementation path focused on the requested engineering outcomes.
+- For code teaching, begin with what the file does, then give each function a short summary followed by detail. Use emojis as visual landmarks.
+- Every standalone lesson must contain the complete code needed for that lesson: full contents for files it creates or changes, including imports, types, and integration/wiring. Do not substitute fragments or links to another lesson for omitted code. Clearly distinguish existing prerequisites from new lesson code, and keep code self-contained and consistent with the course checkout.
+- Preserve substantive implementation exercises: ask the learner to make and defend design choices, implement the relevant slice, and explain what evidence proves and does not prove. Avoid beginner Go instruction and generic conceptual summaries.
+- Keep the Course 7–9 command and session lessons consistent with COURSE.md: in-memory command state is not durable; the Section 8 API is a lab-only unauthenticated endpoint until Section 11; durable command acceptance/recovery begins in Sections 13–14; distinguish retained latest state from queued one-shot delivery and protocol QoS from business effects.
+- Keep lessons short and interactive. Do not mark a concept mastered merely because it appeared in a lesson; wait for the learner's answer or implementation. The request to create lessons is not evidence that Lessons 6–18 have been completed.
+- Keep examples in the disposable lab and do not modify production systems.