Tighten entitlement and file-set signature typing once the service always returns them

[thecodedrift]

#406 ships assuming the service's new fields might be present, so the CLI is not blocked on server work. This issue is the follow-up: tighten once they always are.

Current state (measured 2026-09-27 against GET /cli/api/__schema)

• entitlement (taskless/taskless#207) is not in the live schema yet. fix(check): fail when the server withholds runtime rules for entitlement #406 reads it through MayCarryEntitlement<T> (packages/cli/src/api/entitlement.ts), an optional unknown that goes through parseEntitlement before use. Absent means entitled.
• signature on config-based file sets. The live schema has dropped signature from the sg and vale variants of rules[] on request retrieval and restore (/cli/api/request/{requestId}, /cli/api/request/{requestId}/restore, and the legacy rule/* aliases). The runtime variant still carries it, so restore's check.ts verification is unaffected. The cloud plans to restore it on config-based files.

The vendored api.schema.json was deliberately not regenerated in #406: a refresh now would vendor the missing static signatures, and it also brings in the unrelated successCases/failureCases change (strings or multi-file cases), which is its own CLI change.

When the service always returns both

1. Regenerate api.schema.json / api.d.ts (pnpm --filter @taskless/cli generate:api), reviewing the diff rather than accepting it wholesale.
2. Drop MayCarryEntitlement in favor of the generated field in api/restore.ts and commands/rules.ts.
3. Decide whether the CLI should require a signature on static file sets (refusing a delivery without one) the way it does for runtime. That is a behavior change and a separate spec requirement, not a type tweak.

Refs #403