gui/settings-manager: recompute unit labors after work detail import

[Alistair-Afton]

Fixes DFHack/dfhack#5503 (stacked on #1630).

Importing work details changed each detail's allowed_labors but left every unit's effective labor flags untouched. Jobs that depended on the imported details — like Mechanics and Jeweler's workshops in the report — found no workers until some later action happened to trigger recomputation.

Changes in load_work_details:

• Call dfhack.units.setAutomaticProfessions() for all citizens after importing, matching what the game does when work details are applied through the labor UI. This removes the documented caveat that imported details only take effect after making a change on the work details screen.
• Match saved built-in details by icon when the name no longer matches, so settings exported before a built-in was renamed (by the user or a DF update) still apply. Custom CUSTOM_*/NONE icons are never treated as built-ins.
• Re-read the settings file before each load so a file swapped in while the game is running is seen by load commands and overlay buttons.
• Skip malformed saved entries (missing flag data) instead of erroring.

Also updated the docs to remove the now-obsolete caveat.

Test plan

• New in-engine tests cover icon-fallback matching, the citizen labor recompute call, malformed entry handling, and that custom icons can't shadow built-ins
• Verified live: loaded the reporter's settings-manager.json into a running fort; renamed built-ins received their saved labors, custom details were recreated, and assigned units' status.labors match their detail's allowed_labors (0 mismatches)
• test -t settings in-engine: 7/7 pass
• Full scripts suite in-engine: 30/30 pass; full dfhack suite: 58/58 pass