Customer: expose name + add CustomerEndpoint::update() for name & email

[sandervanhooft]

Problem

The Customer resource is missing a name field on the read side, and CustomerEndpoint has create, get, page but no update method — so even simple identity changes (name, email) can't be made through the SDK.

Scope clarification — Customer vs BillingAddress

This ticket is customer-identity only (1:1 fields on the customer). Billing addresses are a separate concern: 1:N per customer in the data model (each subscription/order locks to a specific address at signup time — preserves tax integrity as customers add/change addresses over time). Billing-address read-back stays subscription-bound via the existing Subscription::\$billingAddress, and billing-address updates stay on the hosted billing-update form (createBillingUpdateLink()) by design.

What this ticket fixes is just the identity layer.

Surface changes

1. Customer::\$name

Add the field to the resource. The api-php Customer resource currently exposes id / resource / email / createdAt / testmode / metadata / links — no name. Hydrate from the API payload via ResourceFactory.

class Customer extends BaseResource
{
    public string \$id;
    public string \$resource;
    public ?string \$name = null;            // NEW
    public ?string \$email = null;
    public ?string \$createdAt = null;
    public bool \$testmode;
    public \$metadata;
    public CustomerLinks \$links;
    // ...
}

2. CustomerEndpoint::update(string \$id, array \$payload): Customer

Restricted to name + email:

\$customer = \$client->customers->update(\$customerId, [
    'name' => 'New Name',
    'email' => 'new@example.com',
]);

Partial payloads accepted. Address / VAT / company fields are deliberately not exposed here — those go through the hosted billing-update flow.

Why this matters

Lets SDK consumers ship a simple in-app "Edit account" form (name + email) on top of an existing customer record, without bouncing users to the hosted form for what's a one-input change.

Open question

Does Vatly's HTTP API expose a PATCH /customers/{id} for name + email today, and does GET /customers/{id} return name? If no, upstream-blocked on the API.