Add new examples and fix original examples of how to use study framew…

[adamwhite629]

Description
Implemented a full suite of data‑quality study scripts under src/zepben/examples/studies/data_quality_studies/, plus a summary runner that builds a single study containing only layers where anomalies are detected. Added “no anomalies detected” placeholder layers to individual studies so they always upload cleanly. Added zone override support for all DQ scripts and a README describing usage. Also improved transformer density map readability (larger circles, black text with halo). No new dependencies were added.

Skipped/Not done:

No unit tests added (these are integration scripts requiring live network access).
Changelog not updated.
CPM summary run timed out even with extended timeout (needs batching or per‑feeder execution to validate in full).
Associated tasks
None. No related PRs.

Test Steps
Run the data quality scripts on a zone (examples):

connectivity_gaps.py NSK
consumer_mapping_issues.py NSK
phase_conductor_issues.py NSK
asset_attribute_inconsistencies.py NSK
protection_directionality_anomalies.py NSK
spatial_location_anomalies.py NSK
Run summary:

data_quality_summary.py NSK
Notes:

Summary run for CPM timed out even with 900s. For CPM validation, either run per‑feeder or extend batching (not done in this PR). TODO process feeders in parellel

Checklist
If any of these are not applicable, strikethrough the line like this. Do not delete it!. Let the reviewer decide if you should have done it.

Code

• I have performed a self review of my own code (including checking issues raised when creating the PR).
• I have added/updated unit tests for these changes, and if not I have explained why they are not necessary.
• I have commented my code in any hard-to-understand or hacky areas.
• I have handled all new warnings generated by the compiler or IDE.
• I have rebased onto the target branch (usually main).

Security

When developing applications, use following guidelines for information security considerations:

• Access to applications should be protected with security keys/tokens or usernames and passwords;
• All sessions are encrypted if possible;
• All application input is sanitised before being acted on (ie SQL statements, etc);
• Log messages, and especially client-facing ones, must be handled securely and must not leak credentials information (internal URLs, passwords, tokens).

• I have considered if this change impacts information security and made sure those impacts are handled.

Documentation

• I have updated the changelog.
• I have updated any documentation required for these changes.

Breaking Changes

• [ x] I have considered if this is a breaking change and will communicate it with other team members by posting it on the Slack breaking-changes channel.

Please leave a summary of the breaking changes here and then post it on the Slack breaking-changes channel to notify the team about it.

Screenshots

Remove this section if the change cannot be shown through screenshots. Frontend changes should mostly include this section.
Screenshots can be copy-pasted into Github textboxes and a link will automatically be generated.
Remove this text if you choose to use this section.

Before	After