Hello again...   Thought I’d post a more-complete answer to my own question, just for the benefit of the next Gentle Reader Monk to stumble upon this thread.   My initial stumblings (and, as it were, the previous post-replies) are in fact somewhat incomplete and therefore misleading.   They identify the underlying self-destruct mechanism, yes, but they don’t pinpoint the right way to use it.

Modules such as e.g. Plack::Handler::FCGI have a manager option, which can either be the name of, or an instance of, a FCGI::ProcManager subclass.   (If none is specified, FCGI::ProcManager itself is used.)

One such manager-class just happens to be:   FCGI::ProcManager::MaxRequests, which among other things allows a max-requests value to be specified.   One convenient way to do this is by using the PM_MAX_REQUESTS environment variable (set e.g. by means of the SetEnv directive in Apache).   If the module looks for this variable and doesn’t find it (or if, by whatever means, the limit-value is omitted), the limit is assumed to be zero which of course means, “no limit exists.”   (A negative value is also taken to mean, “no limit exists.”)

Certain parameters of the Plack::Handler::FCGI constructor (namely, pid and nproc) are actually implemented by passing them to the Manager object if it is auto-instantiated, and must be omitted if instead you choose to provide a manager-object instance of your own.

If you peek underneath the covers of Plack::Handler::FCGI, you will see that it employs the “harakiri” capability.   Obviously, this is the approved way to do so, because it issues certain obviously-necessary calls to the proc-manager object along the way.

Now we know.   HTH™ ...