ING-84 feat(wallets): Accept billingEntityId on updateCustomerWallet

[mariohd]

ING-43 made Wallets::UpdateService accept billing_entity_id and billing_entity_code behind the multi_entity_billing feature flag, but the GraphQL updateCustomerWallet mutation did not expose billingEntityId as an input argument. That meant REST callers could move a wallet between entities while GraphQL callers could not — the frontend had no way to drive the flow. This PR closes the gap.

The change is minimal: a single argument :billing_entity_id, ID, required: false added to Types::Wallets::UpdateInput, matching the placement that already exists on CreateInput. The mutation resolver at Mutations::Wallets::Update#resolve forwards **args straight to Wallets::UpdateService, so no handler change is needed — the new argument flows through automatically and is gated by the same feature flag as the REST path. Behavior is unchanged for any caller that does not supply billingEntityId, and the generated schema.graphql / schema.json are updated to reflect the new input.

Before and after

	Before	After
updateCustomerWallet accepts billingEntityId	No	Yes, optional
Frontend can move a wallet between entities	Not without REST	Yes
Service-layer wiring	Already in place (ING-43)	Unchanged
Feature gating	n/a	multi_entity_billing (inherited from the service)

Test plan

• bundle exec rspec spec/graphql/types/wallets/update_input_spec.rb — type spec asserts the new argument is accepted as ID.
• bundle exec rspec spec/graphql/mutations/wallets/update_spec.rb — new context "when updating billing_entity_id with multi_entity_billing enabled" turns the flag on, calls the mutation with billingEntityId, and asserts the wallet row is updated.
• Manual: with multi_entity_billing enabled on an organization, run the mutation through GraphiQL and confirm the wallet's billing_entity_id changes.

Migration

None. The new argument is optional and inherits the existing multi_entity_billing feature gate — operators with the flag off see no change; operators with the flag on gain the GraphQL surface automatically.

Out of scope

Only billing_entity_id is exposed, mirroring CreateInput. The REST API accepts billing_entity_code as well, but GraphQL inputs keep to the id-only convention.