Fix inconsistent crafting range

[PatrikLundell]

Summary

None

Purpose of change

Address one aspect of #74232 (frequent crafting abortion). I don't think it's the only cause, though.

Describe the solution

• Change two usages of PICKUP_RANGE -1 to drop the range reduction so the actual crafting uses the same range as the evaluation does.
• Changed a third instance for deconstruction, as it should suffer from the same problem

Describe alternatives you've considered

Try to figure out which of the PICKUP_RANGE -1 radii are correct and which should be changed to the radius itself.
I've done the obvious one, leaving the ones that need evaluation for someone else.

Testing

• Made a test setup where I dropped a multitool 6 tiles N of the companion, a primitive lockpick 2 tiles SW of the companion out on a road away from any storage zones.
• Ordered the companion to craft an improvised lockpick.
• Got the companion to continue crafting.

With the first change only the error message gotten when crafting was started and then immediately aborted changed from the original without any code change.
With the second change the crafting proceeded.

Additional context

Including these two locations, there are others where PICKUP_RANGE - 1 are used:
activity_item_handling.cpp operation are_requirements_nearby in a !found_welder section. Should it be changed?
activity_item_handling.cpp operation can_do_activity_there in the ACT_VEHICLE_REPAIR section. Should it be changed?
activity_item_handling.cpp operation can_do_activity_there in the ACT_MULTIPLE_CRAFT section (the second one I changed)
activity_item_handling.cpp operation can_do_activity_there in hte ACT_MULTIPLE_DIS section. Should definitely be changed together with the previous entry.
activity_item_handling.cpp operation requirements_map. Should it be changed?
activity_item_handling.cpp operation generic_multi_activity_check_requirement (the one @MikasaTanikawa references in a post in the bug report). Should definitely be changed.
activity_item_handling.cpp operation generic_multiactivity_check_requirement. A bit further down. Should it be changed?