Investigate generic agent-facing log inspection tools

[mconflitti-pbc]

Context

#4336 exposes the existing troubleshootDeploymentFailure diagnostic as a Positron agent-compatible command. That tool returns the current Publisher logs and is intentionally scoped to deployment-failure troubleshooting.

We should circle back and determine whether agents need a more general, purpose-built way to inspect Publisher logs rather than continuing to reuse a narrowly named diagnostic tool for broader questions. Related UI/error-surfacing work exists in #4203 and #3879, but neither tracks the agent-tool API.

Questions to investigate

• Which log sources should an agent be able to inspect: the current Publisher log buffer, a specific deployment, Connect/Connect Cloud build or validation logs, or historical runs?
• Should the API support filtering by deployment, time range, severity, operation, or source?
• What structured result would be more useful than returning one unbounded text blob?
• What limits, truncation, redaction, and sensitive-data handling are required before logs enter model context?
• Should generic log inspection be separate from higher-level diagnostic tools that interpret a known failure mode?
• Which capabilities belong in vscode.lm, Positron agent-compatible commands, or both?

Acceptance criteria

• Inventory the log data currently available to the extension and the existing diagnostic/log-related tools.
• Define the intended agent use cases and boundaries for generic log inspection.
• Propose a small, composable tool surface with structured inputs and results, including redaction and output-size behavior.
• Identify overlap or dependencies with Error Handling on rendering failures #4203 and display logs in publisher on content validation failure #3879.
• Create implementation follow-ups once the API shape is agreed.

Related: #4336, #4304, #4305