[johha]

Adds support for data.credentials to the buildpack lifecycle and unifies how credentials are provided across lifecycles. Previously only the CNB lifecycle had a data.credentials field; buildpack apps could only authenticate to private buildpacks by embedding credentials in the buildpack URL. This change makes credential handling consistent between the two lifecycles.

Specifically:

• Buildpack lifecycle data can now store credentials (encrypted at rest, in new encrypted_credentials_json / _salt columns on buildpack_lifecycle_data).
• The manifest gains a unified top-level credentials key that works for both buildpack and CNB apps. The existing cnb-credentials key is kept as a backward-compatible alias. Specifying both is a validation error.
• For the buildpack lifecycle, credentials are injected into the custom buildpack URL (both the url and key entry fields) so the staging git clone - which is driven by key via -buildpackOrder - authenticates. CNB continues to receive credentials only via CNB_REGISTRY_CREDS; its buildpack URL stays clean.
• XOR validation: credentials embedded in a buildpack URL cannot be combined with data.credentials. When the conflict is with already-stored credentials (not supplied in the same request), the error explains how to clear them.
• An explicit credentials: null clears stored credentials; omitting the key leaves them untouched (consistent with the additive manifest contract).
• Credentials are redacted everywhere they surface: GET /v3/apps/:guid lifecycle data, the generated app manifest, the space manifest diff (both the credentials keys and userinfo embedded in buildpack URLs, singular andplural), and audit events.

Example - buildpack app with a private git buildpack:

# manifest.yml
applications:
- name: my-app
  lifecycle: buildpack
  buildpacks:
  - https://github.com/acme/private-buildpack   # no credentials in the URL
  credentials:
    github.com:
      username: acme-bot
      password: <token>

CC resolves the credentials at staging and injects them into the buildpack entry so the clone authenticates (pseudocode):

# BuildpackEntryGenerator#buildpack_entries (custom buildpack branch)
url = inject_credentials(buildpack_info.buildpack_url, credentials)
# inject_credentials: look up credentials[URI.parse(url).host], and if an
# entry with a username exists, set url userinfo -> https://user:pass@host/...
{ name: 'custom', key: url, url: url, skip_detect: true }
# Diego builds -buildpackOrder from `key`, so the authenticated URL is used.

Example - clearing stored credentials:

applications:
- name: my-app
  credentials: null   # explicit null clears; omitting the key keeps them

• An explanation of the use cases your change solves

Operators and developers can authenticate to private buildpacks (buildpack lifecycle) and private buildpack registries/images (CNB lifecycle) using a single, consistent manifest/API field instead of embedding secrets in buildpack URLs. This smooths and unifies the API ahead of further lifecycle work, and avoids credentials leaking into URLs that previously had to carry them inline.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests