cli-plugins: Add generic hook messages

[nico1510]

Summary

Plugin hooks can report status and informational messages, but the CLI currently presents all hook output under "What's next:". Add a GenericMessage response type for messages that need no heading or added indentation.

Each matching plugin hook is invoked once. Generic messages are collected and printed before the shared NextSteps block, whose formatting remains unchanged. Older CLIs ignore the new response type.

Example when different plugins return both types:

Session active

What's next:
    Try another command

Validation: the full unit suite passed using the package selection from make test-unit. Added coverage for mixed plugin responses, one invocation per hook, template expansion, empty output, and invalid responses.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 95.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cli-plugins/manager/hooks.go	90.90%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟢 APPROVE

Lower-confidence findings (not posted inline)

• [low] cli-plugins/manager/hooks.go:122 — Fragile nil-slice sentinel replaces explicit boolean 'matched' flag (confidence: unverified low-severity, below threshold)
  The old code used a dedicated ok bool return value from tryInvokeHook to distinguish 'plugin not matched' from 'plugin matched and produced messages'. The new code uses if messages == nil { continue } as a sentinel. This is correct today because ParseTemplate returns a non-nil slice on success, but the invariant is implicit: if ParseTemplate were ever changed to return (nil, nil) for an empty template, the loop would silently skip the 'empty hook message' debug log line. The old explicit boolean pattern was more self-documenting.

• [low] cli-plugins/manager/hooks.go:55 — Nil map access in runHooks relies on Go nil-map read semantics (confidence: unverified low-severity, below threshold)
  When invokeAndCollectHooks returns early (e.g. context cancelled or no config), it returns a nil map[hooks.ResponseType][]string. In runHooks, reading messages[hooks.GenericMessage] and messages[hooks.NextSteps] from a nil map is safe in Go (returns zero value), and both PrintGenericMessages and PrintNextSteps guard with len(messages) == 0. This works correctly but relies on a subtle Go nil-map read property; returning an empty map instead of nil would be more explicit.

[docker-agent]

Assessment: 🟢 APPROVE

The PR correctly introduces a GenericMessage response type and updates invokeAndCollectHooks to collect both generic and next-step messages into a map[hooks.ResponseType][]string. Nil-map read access in runHooks is safe in Go. The printer correctly sequences generic messages before the next-steps block.

Lower-confidence findings (not posted inline)

• [low] cli-plugins/manager/hooks.go:119 — Nil-slice sentinel for 'no match' implicitly encodes two states (confidence: weak, unverified)