Fix order-dependent DesignManagement::SaveDesignsService spec
This spec uses build_stubbed
, which uses IDs starting at 1000 and
incrementing on their own internal counter. It appears that we had a
combination of specs where this ID matched an actual database ID of a
user with access (probably developer
in this spec file), which is
unlikely but not impossible.
By using non_existing_record_id
as the ID for this stubbed record, we
ensure that can't happen.
See #325544 (comment 534807843) for more speculation here.