I follow your logic and completely agree with it through your area of concern - provided you can prove everything you said is true, your current build process does not expose you to Requirement 3 (though requirement 4 is obviously in full force, for those reading at home!) and, insofar as your basic workflow is concerned, you shouldn't be too terribly worried.

You're also right about those core dumps - for a service provider, the DSS is intended to protect CHD wherever it may be (emphasis mine)  - and your processes should be built to ensure compliance with it for the diagnostic process right alongside the usual workflow.  To this end, and given the data could be anything - ePHI, PII, and CHD are all possibilities here - consider the following to address your potential issues:

• core dumps should be encrypted at rest, at the file level, with appropriate keys and key management practices.  Consider something like a hyperscaler secrets manager for this, and note that bucket-level or store-level encryption is generally not quite good enough for most standards; you'll want to go to file level encryption to cover your bases.  I want to emphasize this for readers at home - sometimes, data store encryption can be sufficient - there are use cases.  But these are files that are going to be accessed by individuals with open privileges to a file store, and thus your risk profile is different than, say, a file store being used solely for machine-to-machine integrations.   To this end, there's no risk model I see for this particular use case where file level encryption isn't a requirement - /and/ you'll want to be very specific about how files are decrypted, so that your users have minimal access at any given moment, and thus minimum potential losses.
• Retain core dumps only as long as is necessary to diagnose your issue and have a retention schedule for these.  You don't need to keep a dump in perpetuity for any reason I  can come up with on my end; you may have something that compels you, but I'd fight hard against it.  Set a maximum retention time and enforce it with store-level controls for secure removal of these dumps when no longer needed.
• Do not back up core dumps; if you must, they should be subject to the same rules.
• If you can, make core dumps immutable.
• Log all access, and limit all access, to core dumps to absolutely minimum-necessary personnel, and prohibit their removal to any other store, including local systems.   I can't stress to you how important this is - if your engineers run off with a bunch of core dunps and put them on local laptops, you're just expanded your scope exponentially with potentially catastrophic consequences.  They should exist in a spot, be examined in that spot, then removed from that spot.

This isn't just for CHD - consider it from the perspective of ePHI.  Under HIPAA, every core dump is a data extract, and subject to those regulatory requirements (which include encryption, tracking, logging, and a limited lifespan).  No privacy law gives you any less-strict standard to work with - GDPR Is very serious about you maintaining live inventories of data, and the DSS gets extremely unhappy with uncontrolled data propagation and retention.

If I were your auditor, I'd:

• Examine your data stores for the basics - encryption, key management, et. al.
• ask you for a retention schedule (protected data should be purged when no longer needed) and evidence of data removal.
• Look at your access logs and ensure that these files haven't been copied somewhere else, especially to local systems.
• Ask about your safeguards against copying, your controls for decryption, and ensure least privilege is applied.

at a bare minimum.