Add the Users.IsActive column so a login can be disabled

[renemadsen]

Step 2 of the "resigned workers can still log in" work — design: microting/eform-angular-frontend#8072 (spec PR #8073). Step 1 shipped EformUser.IsActive in Microting.eFormApi.BasePn 10.0.35 (microting/eFormApi.BasePn#972).

This issue

• bump Microting.eFormApi.BasePn from 10.0.30 to 10.0.35
• map EformUser.IsActive with HasDefaultValue(true)
• add the migration for Users.IsActive

Two things the migration must get right

1. defaultValue: true, written explicitly. A naively scaffolded defaultValue: false disables every existing account on migrate. Copy the precedent at 20250904105541_AddOAuthLoginSupport.cs:41-46.
2. The mapping's HasDefaultValue(true) pairs with the = true initializer already shipped in BasePn. HasDefaultValue(true) makes true the property's sentinel; EF Core omits a sentinel-valued column from the INSERT so the store default applies. The initializer is what stops a freshly constructed EformUser holding false and being written explicitly — which would create every new account disabled.

ExternalLoginEnabled is the cautionary example: it is a shadow bool with HasDefaultValue(true), and a shadow property cannot carry an initializer, so every user created since that OAuth migration has it stored as 0 despite the declared default. Dormant only because nothing reads it.

Consumer note

Once this is released, the host release that picks it up must carry both this package and BasePn 10.0.35 together. IdentityDbContext maps the property by convention and the host materialises whole EformUser rows during boot, so a BasePn bump without this column stops the host from starting.

Nothing reads the flag yet — the login refusals are step 3 (eform-angular-frontend) and writing it on resign is step 4 (the plugins).