#1268 Scaleway models: create methods should not require the resource ID they generate (ipId/gatewayId/serverId/...)

Problem

Across the local @sntxrr/scaleway-* model family, each model declares its primary resource ID as a required globalArgument (ipId, gatewayId, serverId, vpcId, clusterId, namespaceId, volumeId, instanceId, ...). But the create method generates that ID — it uses the API's returned id and only falls back to g.<id> (e.g. const newId = (res.id as string) ?? g.ipId; in scaleway-ipam).

Because the field is required by the Zod schema, driving create from a workflow (or CLI) forces a meaningless placeholder purely to pass schema validation:

inputs:
  ipId: pending        # ignored by create; only satisfies validation
  gatewayId: pending   # same

Impact

• Every provisioning workflow needs placeholder globalArgs, which is confusing and error-prone.
• Discovered while building the a1-public-endpoint workflow: ipam.create -> public-gateway.create(ipId) -> dns.update.

Affected models (non-exhaustive)

• @sntxrr/scaleway-ipam — ipId (create books a new IP)
• @sntxrr/scaleway-public-gateway — gatewayId
• @sntxrr/scaleway-elastic-metal, @sntxrr/scaleway-apple-silicon — serverId
• @sntxrr/scaleway-vpc (vpcId), -kapsule (clusterId), -registry (namespaceId), -rdb/-redis/-mongodb, -block-storage (volumeId), and others with a create method.
• Related: @sntxrr/scaleway-instance requires serverId for all methods but has no create/delete.

Proposed solution

Make the primary resource-ID globalArgument .optional(), and validate its presence at method entry only for methods that operate on an existing resource (sync/update/delete/action). create already ignores it. Smallest change; keeps a single GlobalArgsSchema per model.