v1.60.0 - usercentrics 1.7.0

A granting Usercentrics resource, beside the refusing one.

usercentrics-accept.js is the same record with the answer the other way round:
every service the record already names is consented, updatedBy is their
onAcceptAllServices, the name-keyed consentStatus.services map is all true,
and their Google consent mode is granted with adsDataRedaction: false. The v2
uc_settings statuses agree.

What it cannot do is in its header, because it matters more than what it can:

• A first visit grants nothing. Their service ids come from the settings
  payload this resource exists to avoid fetching, and their blocker treats an id
  it was never told about as blocked. So this is for a wall a returning visitor
  finds shut, not a default - there is a test pinning that case, because it is
  the one most easily mistaken for a bug.
• It grants their services, not IAB consent. On a TCF tenant the TC string
  still refuses: consenting there means naming the purposes, special features
  and vendors in the tenant's own configuration.
• Global Privacy Control is untouched. A browser signal stands on its own.
• consentHash is not forged. It differs per visitor for the same consent
  state, so it is absent rather than invented.

Point it at a site by name. filters/usercentrics.txt carries a commented
example with a domain=, so it cannot be enabled everywhere by accident.