Make your own decisions

The answer to 'So how actually can developers ever develop a story if there are no lower requirements?' is very simple - the detailed requirements that are orthogonal to the needs of the end user (e.g. DB constraints, fields validation, etc) don't actually matter to the user. If the user needs can be met by very different fields validation, very different DB structures or perhaps even no traditional DB at all, then it would be counterproductive to askhave the users formake up such information with a particular implementation in mind, which may be very different from how the system is implemented in the end.

You're professional developers, so make professional decisions to the best of your ability about implementation details. An user who wants a table can tell a carpenter what type of wood they'd like, but the carpenter is expected to decide how thick the table legs should be to handle reasonable loads. If you lack some information to make a meaningful decision, then that needs to be discussed with the user, but some 90% of content for a detailed requirements document actually does not need any information aside from the vague user stories common sense and industry best practices.

All those details aren't arbitrary - there are bad choices and better choices, and they should be documented since they affect other parts of the implementation, but in the end they are still implementation details that can and should be decided by the implementing team according to user needs and best practices.

A standard car analogy - if a customer wants the car painted red, then an appropriate clarification for the user story would be to ask which shade of red would be better, but not the chemical composition of the paint; nonetheless it would be expected that they wouldn't choose to paint the car with watercolors that would wash out in the rain, since it's best practice not to do so.