Use explicit client_type claim for client-token tenant resolution #627

Follow-up to PR #626: #626

Update the EstateContext middleware to distinguish user tokens from client-credentials tokens using an explicit issuer-controlled client_type claim.

Requirements:

• Treat a token as a client token only when client_type explicitly identifies the client-credentials/service token.
• Do not infer “client token” from a missing ClaimTypes.NameIdentifier, missing estateId, or the presence of client_id.
• For user tokens, require a valid estateId claim and verify it matches the optional estateId header.
• For client-credentials tokens, require a valid estateId header and use it as the tenant context.
• Require the expected audience and service scope as additional authorization safeguards.
• Add or update tests covering:
  • User token with a valid estate claim.
  • User token with no estate claim.
  • User token with a mismatched estate header.
  • Client token with a valid estate header.
  • Client token without an estate header.
  • An authenticated token without the explicit client marker being treated as a user token, not a client token.
• Keep the claim name/value and any accepted service scope configurable or documented as part of the token contract.