SDK 4.8.0 — first-send tax fields now follow the sender

A sandbox sender can carry only a routing or legal identifier, or it can also carry a Tax Identifier. No single static invoice is valid for both shapes: Storecove rejects tax-bearing content without a Tax Identifier, and rejects an outside-scope O/0 fixture when a Tax Identifier is present.

SDK 4.8.0 exposes the answer returned by GET /v1/identity:

const identity = await peppol.identity.get();
if (identity.sandboxFirstSend?.status !== "ready") {
  throw new Error(identity.sandboxFirstSend?.message ?? "Sender not ready");
}

await peppol.invoices.send({
  // recipient and invoice fields
  lines: [{
    description: "Integration test",
    quantity: 1,
    unitPrice: 100,
    ...identity.sandboxFirstSend.line,
  }],
});

The profile is derived from the exact Storecove Legal Entity inventory, not from a country guess or only the local database row. It returns O/0 for a routing/legal-only sender and AE/0 when a Tax Identifier is present. If the inventory cannot be read, or its aggregate tax role cannot be established from the audited Provider Tax/Legal registry, the profile is blocked — there is no static fallback. A known Tax Identifier is positive proof even when a separate routing scheme is not classified.

The invoice endpoint independently reads that same exact provider inventory immediately before document submission and refuses either mismatch locally. This covers standard sends, platform send_as, provider-renamed schemes, and provider-derived Tax Identifiers.

CLI 0.9.0 consumes this profile automatically. It adapts its own integration fixture, but never rewrites a user-authored invoice silently.