rsconnect deployment log ends at package restore: locating the real failure point

When publishing content from the RStudio IDE to Posit/RStudio Connect via the rsconnect workflow, the Deployments pane shows a log covering bundle creation, upload, and the server-side package restore. The summarized output can truncate the underlying install or compile errors, which makes it hard to tell whether a failure happened during dependency resolution, a missing system library, or at application startup after a client-side "success" message.

The goal is a reliable diagnostic procedure: given a deployment whose log stops during the restore step, determine where the failure actually occurred and which log source is authoritative. Constraints: behavior is version-sensitive across rsconnect and Connect releases, the generated manifest.json may pin package versions that drift from what the server restores, and logs shared for review must not expose credentials or API keys.

Which rsconnect options or settings expose the full, untruncated build output when the IDE log summary hides the underlying error?

How should the client deployment log be cross-checked against the Connect server's per-content build and runtime logs to distinguish a restore failure from a startup failure?

When comparing manifest.json against the server's restored library, what is the practical way to confirm version drift is the cause rather than a missing system dependency?