feat: add workflow-definition-field-id to SignInFieldAttributes

[mellwood-envoy]

Summary

Adds one attribute to SignInFieldAttributes:

'workflow-definition-field-id'?: string | null;

envoy-web sets it on a sign-in field when a workflow policy owns that field, and exposes it on the v3 sign-in-fields resource as readonly :workflow_definition_field_id alongside created_at and updated_at. The column is a nullable uuid, so the value is a string when present and null otherwise.

Why

When a policy is associated to a flow that already carries an integration's sign-in field, envoy-web adopts that field for the policy. From then on the field has two interested parties, and an integration that later un-requires or deletes it on flow removal breaks the policy. The only signal that this has happened is this attribute, and the type gave consumers no way to read it.

envoy-integrations-internal-sdk #242 teaches EnvoySignInFieldFlowManager.cleanupFlows to leave such fields alone, but has to widen this interface locally to do it:

export type SignInFieldWithOwnershipModel = JSONAPIModel<
  SignInFieldAttributes & { 'workflow-definition-field-id'?: string | null },
  SignInFieldRelationships
>;

With this merged and released, that type comes out and getFieldById goes back to returning SignInFieldModel.

Optional and nullable

Optional to match the other attributes and because the server ignores it on create and update, so nothing building an attributes literal needs to supply it. Nullable because a read returns null for every field a policy has not adopted.

Verification

prettier --check, tsc --noEmit, and eslint clean. Test suite green: 5 suites, 72 tests. Type-only change, so no new tests.

Version bumped to 2.5.4 in package.json and package-lock.json, matching how #120 handled the last additive attribute change (2.5.2 -> 2.5.3). Publishing still happens on release creation, so this only stages the version.

🤖 Generated with Claude Code