Support expanded server tags and real database tag semantics

Problem

Server and database tags have inconsistent capacity and semantics:

• Server tags are too narrowly constrained across storage, API, and UI layers.
• DB_Type is displayed as semicolon-separated tags, but backend queries and variable resolution treat the full value as one opaque category. A value such as Endur;Reporting therefore renders as two tags while failing tag-based matching.

Scope

• Increase server tag and DB_Type capacity to 4000 characters across SQL, EF, API contracts, Swagger, and UI validation.
• Treat DB_Type as an exact, semicolon-delimited tag set everywhere it is queried or compared.
• Emit deployment variables per individual database tag.
• Reject invalid multi-tag or empty single-tag lookup parameters.
• Add database tag chip editing, normalization, and joined-length validation in the UI.
• Provide pre-deployment auditing and idempotent normalization for legacy database tag values.

Acceptance criteria

• Multi-tag databases match each individual tag without substring matches.
• Database deployment variables are generated per tag, becoming arrays when a tag maps to multiple databases.
• Null database types do not break variable resolution.
• Values up to 4000 characters are accepted consistently; longer values are visibly rejected before submission.
• Existing padded, duplicate, and colliding tag data can be identified before rollout and normalized during deployment.
• Automated tests verify storage/API/UI limit agreement and tag behavior.

Implementation

Implemented by #774.