Spec 0008 D5, rung 1 of the ladder in D10. NewProviderFromClient takes a
*github.Client the caller already holds — a GitHub App installation transport, a
rotating token source, an enterprise proxy — and builds a provider on it.

The rung TRANSFERS THE CREDENTIAL OBLIGATION, exactly as WithHTTPClient (D4)
transfers the redirect-policy obligation. The client carries its own
authentication and this provider adds none, so Settings.Credential must be nil.
Supplying one is ErrCredentialWithClient rather than a silent preference: a
caller would otherwise believe their credential is in play when the client's is,
and find out only when a permission differs.

Settings.APIURL and Settings.UploadURL are refused for the same reason. They
configure the client this module would otherwise BUILD, so alongside an injected
one they are read by nothing — a caller setting them is addressing an instance
the provider will never contact.

That second guard exists because of a mutant that survived. The first version
copied the URLs off the client into Settings and had a test asserting the
provider follows the client rather than a stale Settings URL. Deleting the copy
did not fail the test: those fields are consumed only by enterpriseURLs, which
this path never calls, so the assignment was dead and the test was vacuous. The
honest fix was to refuse the fields rather than pretend to read them.

Asset downloads keep working, which is why this rung is fully useful on GitHub
and only partly so elsewhere. go-github makes the authenticated hop to the API
with the caller's client, stops at the redirect, and follows it with the
credential-free client this adapter builds — so a private asset resolves through
the caller's authentication without that authentication reaching the
author-controlled storage host.

Every guard is falsified against the mutant that removes it.