fluidpage: `sortindex` by context-pass-through fails file-picker to list entries

[phorward]

Given the following scenario:

1. Open a Fluidpage Editor view
2. Add a new element
3. Select "Image"
4. On the provided "Image"-bone, click "select file"
5. The File module selector appears, but no files are listed, only folders

The reason for the problem (simplified, using shortkeys):

• This URL is called in a bare file module: /vi/file/list?skelType=leaf&orderby=sortindex&limit=99&parententry=5086640280174592
• This URL is being called in the fluidpage-context: /vi/file/list?skelType=leaf&orderby=sortindex&limit=99&fluidpage.dest.key=5753836807389184&fluidpage=5753836807389184&sortindex=1754657051.5975206&parententry=5086640280174592

The problem here is the sortindex=1754657051.5975206 which is being provided. It filters the file-entities by their sortindex, which must be exactly 1754657051.5975206 which is never the case and not a wanted behavior here.

Changing the context-url manually into /vi/file/list?skelType=leaf&orderby=sortindex&limit=99&fluidpage.dest.key=5753836807389184&fluidpage=5753836807389184&parententry=5086640280174592 (omitting the sortindex-parameter) brings the correct list.

Proposed solution: Context-variables should be marked by a preceding @ to keep a context up, which would make @fluidpage the only valid context variable which must be evaluated server-side. Any other parameter could only be relevant to the nearest context call, so the sortindex=1754657051.5975206 is only relevant to the preceding fluidpagecontent/add call.

It is generally bad practise that both fluidpage.dest.key and fluidpage are provided as contexts. This should be replaced by @fluidpage in vi-admin 5.

Now one can just remove a sortindex from further context propagation, but this is a bad hack which will again require a (statically defined?) blacklist of names that are relevant.