Linter rule suggestion: Flag sensitive values that are used in non-sensitive places

> Maybe a separate issue, but we should in general be flagging whenever a sensitive value is assigned to a non-sensitive slot or vice versa. For example, the following template raises no diagnostics but should raise two:
>
> ```bicep
> @secure()
> param secret string
>
> param nonSensitive string
>
> resource e 'Microsoft.CostManagement/exports@2024-08-01' = {
> name: secret // <-- Should flag assignment of sensitive data to non-sensitive slot
> properties: {
> definition: {
> timeframe: 'BillingMonthToDate'
> type: 'Usage'
> }
> deliveryInfo: {
> destination: {
> container: 'containerName'
> sasToken: nonSensitive // <-- Should flag assignment of non-sensitive data to sensitive slot
> }
> }
> }
> }
> ```
>
> We should be able to do this based on existing type validation flags. I'm not sure if we accurately track "taint," though (i.e., is a variable whose value is based on a secure parameter itself be flagged as secure?).

_Originally posted by @jeskew in [#15835](https://github.com/Azure/bicep/issues/15835#issuecomment-2539505563)_

Start by tracing the existing type validation flags referenced in the issue and how sensitive values are represented. Define how assignments to sensitive and non-sensitive slots should produce diagnostics, including whether derived values retain sensitivity. Done means the example reports both incorrect assignments and the taint behavior is covered by tests.

Written by the indexing model from the issue text.