OSM source is pinned to a frozen commit and excluded from the default build

Summary

Two coupled limitations make the OSM source (added in #272) easy to misuse:

1. Pinned to a frozen commit. The OSM config url points at open-energy-transition/osm-powerplants commit 13bb6a3. Manual OSM corrections (e.g. fixing plant capacities for a country a contributor maintains) never reach ppm unless that pin is bumped, and there is no documented refresh path.
2. Excluded from the default build. OSM is loadable via pm.data.OSM() but is not in matching_sources or fully_included_sources, so powerplants() contains no OSM data by default. This is surprising and undocumented.

Why it matters

OSM is often the best (or only) source for plants curated by a local contributor. Pinning + default-exclusion means those corrections are invisible to ppm users, and users do not realise OSM is absent from their combined dataset.

Data quality note

OSM loads cleanly: 12,917 plants, 35 countries, ~570 GW, zero NaN coordinates/capacity. With a Capacity >= 1 filter and the same German-VRE exclusion the other sources use (MASTR owns German wind/solar), it integrates fine into both matching and fully-included paths.

Proposal

1. Document the pin-bump / repoint workflow for the OSM source (and consider tracking a branch/tag instead of a commit, or a dated release).
2. Offer an opt-in to include OSM in the default source lists, with sensible capacity filters and VRE exclusions.

Relates to #242, #243, #244 (OSM data-quality / category support) and #273 (duplicate assets, relevant to OSM dedup).

Start by tracing pm.data.OSM(), matching_sources, fully_included_sources, and powerplants() to understand the current OSM pin and source-list behavior. Review the related issues for data-quality and deduplication constraints. Done means documenting the refresh workflow and defining an opt-in OSM path with the stated capacity and German-VRE filters.