Improve logging

Problem/Motivation

The login_disable module currently emits no log entries. Several of its code paths sit close to authentication and access decisions, where logging would help administrators diagnose why a user could or could not log in.

Because the module is silent, sites relying on it have no trail in admin/reports/dblog or syslog to correlate with other authentication signals. Adding structured logging lowers the operational cost of running it.

Steps to reproduce

Not applicable — this is a scoping issue, not a bug report.

Proposed resolution

Investigate where logging in this module adds value. Decide on:

• which events warrant a log entry;
• which log level fits each event (info, notice, warning, error);
• whether to introduce a dedicated logger channel (login_disable) so administrators can filter easily;

The concrete code changes will be broken out into follow-up child issues once the direction is agreed.

Remaining tasks

• Enumerate log-worthy events in the current codebase.
• Agree on logger channel and levels.
• Draft example log messages for review.
• File child issues implementing each logging point.

User interface changes

None.

API changes

Likely adds a login_disable logger channel service. No other public API changes anticipated at the planning stage.

Data model changes

None.