Application.start/1 {:error, reason} in release startup logs

A release deployment diagnostic is needed that relies on startup log error tuples to pinpoint the exact initialization barrier for an Elixir/OTP release application. The goal is to correlate Application.start/1 return values with supervisor shutdown signals and release verbose markers to distinguish a failure in the application supervisor from a failure in a child process.

The interpretation is constrained by documented variability in exit reason tuple formats across OTP and Elixir releases, and by the effect of release compilation options on debug information availability for {function_clause, ...} descriptions. Application type flags permanent, transient, temporary in the release manifest also govern automatic restart behavior, which can mask or amplify repeated failure patterns in logs.

What mapping should be assumed between {:shutdown, {trap_exit, reason}} emitted by OTP supervisors and the {:error, reason} returned by Application.start/1 during release startup? When does a release build retain sufficient BEAM symbol data to make {function_clause, ...} descriptions actionable in logs without additional configuration? Does the :application type flag alter how =PROGRESS= and =CRASHERS= markers should be read for a given application?