[ADD] Explicit job timeouts in ci_dotnet.yml and ci_dotnet_azure.yml

[plamber]

Follow-up from EasyLife365/EasyLife365-Identity#1065 (decision 2026-09-25).

Feature Summary

As an EasyLife engineer, I want the shared .NET CI workflows to have explicit job timeouts, so that one hung test run cannot hold a runner, and a non-cancelling concurrency group, for up to six hours in every product that calls them.

Detailed Description

Current behaviour.

• ci_dotnet.yml (475 lines) and ci_dotnet_azure.yml (517 lines) contain no timeout-minutes anywhere, so every job gets GitHub's default of 360 minutes. spa_build.yml already sets one.
• Callers that run the integration lane under a concurrency group with cancel-in-progress: false feel this most. Identity's hourly integration.yml and el-release.yml are examples: a single hung run blocks both the hourly lane and releases until the six hours expire.

Wanted behaviour.

• Both workflows set timeout-minutes on every job, with defaults that fit today's real durations.
• A caller can override the defaults through an input, for the rare slow lane.

Acceptance criteria

• Every job in ci_dotnet.yml and ci_dotnet_azure.yml has a timeout-minutes. The defaults are based on the P95 duration over the last 30 days of runs across the calling repositories, recorded here. Proposal: unit lane 20 minutes, integration lane 30 minutes.
• A caller can raise the timeout with a workflow input without forking the workflow.
• A run that exceeds the timeout fails with GitHub's timeout message, and the next run in the same concurrency group then starts.
• Existing callers (Identity, Collaboration, Exchange, Notification, EasyHub, Approvals, Core) pass unchanged on their next run.

Additional Context

Proposed priority: Prio2. Found while reviewing Identity's CI (EasyLife365/EasyLife365-Identity#1058).