[Panelize][Added] Rail widener for pick-and-place sensor detection

[Reid-n0rc]

Closes #953

Summary

Adds a "rail widener" to the panelize output: a solid patch of extra rail/frame material at chosen outer panel corners (tl/tr/bl/br), so pick-and-place photoelectric sensors get a bigger flat target without growing the panel's outer outline or ever overlapping a board.

• New framing.widenercorners/widenerwidth/widenerlength/widenergap options, valid for framing.type railstb/railslr/frame/tightframe.
• Implemented as a KiKit FramingPlugin (kibot/panelize_plugins/rail_widener.py) that delegates to KiKit's own framing builder for the requested base type, then unions in the corner patch(es).
• The patch is clipped against the board outline(s) (expanded by widenergap, defaulting to the frame's hspace/vspace) so it can never touch/overlap a board, with an extra allowance for KiKit's own reverse-tab-fillet pass so the gap that survives matches what was requested.
• The new concave "step" corner where the patch returns to the normal rail width gets an exact tangent-arc fillet (radius = framing.fillet), computed directly from the corner/step geometry so it only affects that one point.
• Updated PanelDemo_4x4.kibot.yaml to demonstrate widening the top corners.
• Regenerated the PanelizeFraming docs for the new options.

Test plan

• Ran the demo config (4x4 panel, railstb framing) through kibot and inspected the generated panel/preview: widened patches appear at the requested corners, never overlap the boards, and don't grow the panel outline.
• Verified with widenercorners on all four corners at once, and with a widener width/length deep enough that it would otherwise overlap a board, confirming the clip.
• Opened the generated panel in pcbnew to visually confirm the patches and the step fillet.
• No automated regression test added yet under tests/test_plot/ — happy to add one if you can point me at the preferred board sample/pattern for panelize tests (I noticed tests/board_samples/*/light_control.kicad_pcb is used for other panelize tests).

[set-soft]

Hi @Reid-n0rc !
The option looks good. Here are some details:

1. The docs should explicitly say this option will modify the code and arg. In fact a check to see if these options were defined by the user can help to catch silly errors, just report an error when the user tries to use it and also to specify another plug-in. I wonder is its possible to create some sort of wrapper that might allow both things (explicit and implicit plug-ins)
2. I think we should keep the panel example template without modifications, just create an example in the tests/yaml_samples/ dir. Similar to the demo, but oriented to test the feature. Why? If the KiKit API makes your plug-in obsolete it will break the basic example.
3. For the test you can add some very silly board, might be just a rectangle, and apply the test configuration. Using light_control for this is an overkill. Just try to verify the widener. Why: KiCad changes things like zone fillers, fonts, etc. and they break the light_control reference from time to time, keeping this test as simple as possible will make reference updates less common.

[set-soft]

Hi @Reid-n0rc !

Please address these items. Also: if the plug-in was created using Claude assistance please mention it.

Hi @Reid-n0rc ! The option looks good. Here are some details:

1. The docs should explicitly say this option will modify the code and arg. In fact a check to see if these options were defined by the user can help to catch silly errors, just report an error when the user tries to use it and also to specify another plug-in. I wonder is its possible to create some sort of wrapper that might allow both things (explicit and implicit plug-ins)
2. I think we should keep the panel example template without modifications, just create an example in the tests/yaml_samples/ dir. Similar to the demo, but oriented to test the feature. Why? If the KiKit API makes your plug-in obsolete it will break the basic example.
3. For the test you can add some very silly board, might be just a rectangle, and apply the test configuration. Using light_control for this is an overkill. Just try to verify the widener. Why: KiCad changes things like zone fillers, fonts, etc. and they break the light_control reference from time to time, keeping this test as simple as possible will make reference updates less common.

[Reid-n0rc]

Thanks for the review, @set-soft! Addressed in 371b69c:

1. code/arg override: the widenercorners docs now explicitly say it overwrites type/code/arg, and PanelizeFraming.config() now raises a KiPlotConfigurationError if the user also sets code/arg explicitly instead of silently clobbering them. I kept it to that explicit check rather than building the implicit/explicit-plugin wrapper you floated — didn't want to add that abstraction speculatively without a concrete second use case driving its shape, happy to revisit if you have one in mind.
2. Demo template: reverted PanelDemo_4x4.kibot.yaml back to unmodified; the widener example now lives in its own tests/yaml_samples/panelize_widener_1.kibot.yaml.
3. Test board: test_panelize_widener_1 now uses simple_2layer (already used elsewhere in the suite) instead of light_control.

While wiring up that test I actually caught a real bug: widenercorners/widenerwidth/widenerlength/widenergap were leaking into the JSON preset handed to the kikit CLI, which doesn't recognize those keys and failed with 'list' object has no attribute 'split'. Fixed by excluding them from the preset once they're folded into arg. Verified locally (KiCad 10 + KiKit) that the test now runs and the panel renders as expected.

Also, yes — Claude assistance was used throughout this PR (implementation and this round of fixes), noted via Co-Authored-By in the commits.