Add tiger service logs command and service_logs MCP tool

[nathanjcochran]

Adds a new tiger service logs command for viewing service logs with colorized output and automatic pagination. Also adds corresponding service_logs MCP tool.

Changes

• Add tiger service logs command with --tail, --until, --node, and --output flags
• Adds service_logs MCP tool (with parameters corresponding to the tiger service logs flags)
• Default --tail to 100 lines with automatic multi-page fetching as needed
• Add colorized output for PostgreSQL log levels (ERROR/FATAL in red, WARNING in yellow, etc.)
• Removes some unused Service fields that were never actually being populated from the backend API. In particular, Paused and VolumeType.

Key Decisions

• Log reversal: API returns logs in descending order (newest first), but terminal convention is oldest first/newest last, so we reverse before displaying
• Default tail: 100 lines is a reasonable default that works for most use cases without overwhelming the terminal or causing a huge number of page fetches (which slows down the command). Users can request more by specifying a larger value for --tail or by specifying an earlier timestamp for --until.

[Askir]

looks good to me, I wonder if the api should take a flag for the log order rather than doing it on the client but either is fine I think.

[nathanjcochran]

looks good to me, I wonder if the api should take a flag for the log order rather than doing it on the client but either is fine I think.

Yeah, I considered reversing the log order in the API layer, but that would make pagination weird. Like, if the logs themselves were returned in the ascending order, but the pages were in descending order (which I can't really change), you'd have to append each page of logs to the beginning of the array when aggregating multiple pages, instead of to the end, which just feels really weird imo. So I decided to keep returning the logs in descending order from the API, so that the log order and page order is the same, and pagination works like you'd expect - i.e. the next page always contains the log messages that would come after the last message in the current array buffer, logically speaking. Then we can just reverse the entire array after aggregating all of the pages together to display them in ascending order, which I think is a little more simple/straightforward/easy to understand.