update "how to add custom study area to landweb" in manual

[achubaty]

https://predictiveecology.github.io/LandWeb/modifying-landweb.html#example-2-adding-a-new-study-area

• per-study area LTHFC maps (temporary stopgap);
• how to allow different layers in LTHFC to be used via e.g., study area name (useful for evaluating different versions of the LTHFC map);
• direct user to add custom study name to the 'allowed' list at the top of InitMaps();

[achubaty]

Scope update (2026-08-06): the documented procedure is not merely stale, it is wrong — and the rewrite is blocked on a design decision rather than on writing.

The current text describes mapAdd() calls in LandWeb_preamble.R plus an 'allowed' list at the top of InitMaps(). None of that machinery runs any more: mapAdd() is not called anywhere on the live path, and reporting polygons come from LandWebUtils::buildReportingPolygons() as a plain named list.

The harder problem: under the new ecoregion-group study areas it is no longer sufficient to add an arbitrary polygon as a study area — a custom area has to resolve to land inside a group. Adding crosswalk rows and listing the group in _local.R covers adding a group, not a custom area within one. Two questions need deliberation before the section can be written:

1. How is a custom area added as a reporting polygon within an ecoregion group? Most likely the same machinery as the reporting-polygon crossing work in restore tenure × sub-region reporting-polygon crossings (ANSR, caribou, landbase, …) #118 (custom polygon × group, keyed by a combined name), so the two should be designed together rather than built twice.
2. What happens when a custom area crosses group boundaries? There is a worked precedent: the Alberta LUF planning regions were measured against the v10 tenure footprint and only 33% of their area falls inside any study-area group (best case Upper Athabasca 49%, worst Red Deer 0%). A reporting area spanning groups gets split, each piece summarized independently, with no cross-study-area roll-up — the per-group architecture deliberately omits one. So a straddling custom area would silently yield per-group fragments instead of one coherent summary. Options to weigh: assign to the dominant group, run it in every group it touches plus a roll-up, or reject/warn at validation time.

Note this is really the general "reporting area doesn't nest inside a study area" problem — LUF, the AB sub-regional plans, and custom polygons all hit it — so it may be worth solving once.

The two original sub-asks (per-study-area LTHFC maps; selecting the LTHFC layer by study-area name) remain valid.