Fetch access logs of add-ons with clever accesslogs --addon #1126

Context

clever logs --addon <id> works, clever accesslogs --addon <id> does not: the option is declared and shows up in accesslogs.docs.md, but the handler rejects it immediately.

// src/commands/accesslogs/accesslogs.command.js
// TODO: drop when add-ons are supported in API
if (options.addon) {
  throw new Error('Access Logs are not available for add-ons yet');
}

The API already supports it

The TODO is stale. The v4 endpoint is /v4/accesslogs/organisations/{ownerId}/applications/{id}/accesslogs, but the applications path segment is a misnomer: server side it is parsed as a LoggableId, a union accepting every add-on prefix (redis_, postgresql_, cellar_, pulsar_, keycloak_, otoroshi_, …), and the handler then reads the Pulsar topic named after that ID. Nothing along that code path is application specific.

Verified against production: the endpoint returns real access logs for a Redis add-on, using its real ID. An addon_ ID matches no topic and streams nothing, so the CLI has to resolve to the real ID (which resolveAddon already does for clever logs).

Second problem: those logs are currently dropped

Add-ons exposed over raw TCP emit access logs with no http section, and both the human and clf formatters skip any log where log.http == null. So even once the stream is wired up, clever accesslogs --addon <redis> would print nothing while events are flowing. The human format needs a line for connection-level logs.

Scope

• resolve --addon to its real ID and stream from it
• render access logs without an http section instead of dropping them
• keep clf skipping them (CLF describes an HTTP request)