the updateOption function that handles the req.param is just destructuring `const { name, value } = req.params;` and does nothing else with the path or any params.
The remaining parts of the wildcard (which can be accessed via req.param[0]) are just ignored here.
even with express v4, this would *always* just take and process the very first part of the path, in the exact wildcard's place, e.g.
`/api/options/locale/de` and
`/api/options/locale/de/test/whatever`
would *both* end up destructuring "value" from req.param as "de" (because it is in the exact place of the 'value' wildcard)
in express v5 the wildcard behaviour changes -> here req.param.value would return an array with the paths split into separate string.
but since the code previously regarded only the first part of the path -> we can just get rid of the wildcard and use a named route param
the only thing to keep in mind: if a request with more than one "value" is received, (e.g. `/api/options/locale/de/test/whatever`) -> since we don't have the wildcard anymore -> this will turn to a 404.
IMHO that is actually desirable here though
since `cookie-parser` is not configured with a secret,
req.secret is not set and hence is `undefined`,
which then is used as literal 'undefined' in the hashing function – making it less secure.
Instead we can use the existing sessionSecret:
the `csrf-csrf` developer confirmed in their Discord chat,
that it would be ok to use the same secret here.
I've kept the identical same settings as before –
however they are not *ideal* from what I read.
More secure settings will need to be tested a bit more thoroughly first and will be a separate PR.
