ModelAdmin: the q[FieldName] search example does not work in CMS 5 / CMS 6

en/02_Developer_Guides/15_Customising_the_Admin_Interface/01_ModelAdmin.md (branches 5 and 6) shows a search field named q[...] pushed onto the SearchContext, and a getList() override reading it back:

$params = $this->getRequest()->requestVar('q');

As far as I can tell that no longer reaches anything. I tested it on CMS 5.4 and CMS 6.2.6 with a FunctionalTest logged in as ADMIN, replaying the request the admin client actually sends when the grid search form is submitted (built from the entwine search handler in the admin bundle):

• the POST body is filter[<GridFieldName>][<fieldname>]=... with X-Pjax: CurrentField, so values arrive through GridState and SearchContext::getQuery(), not as a top-level q;
• getList() saw requestVar('q') === null and the returned list was unfiltered;
• with the field literally named q[OnSale], PHP's body parser also mangles the key to q[OnSale.

A plain field name plus a matching filter passed the same test on both versions:

$context->getFields()->push(CheckboxField::create('OnSale', 'On sale only'));
$context->addFilter(ExactMatchFilter::create('OnSale'));

(Scaffolded search fields are named plainly too: scaffoldSearchFields() does str_replace('.', '__', $fieldName).)

A hand-typed URL ?q[OnSale]=1 does still reach getList(), so the pattern isn't dead everywhere, but the admin grid doesn't produce that URL. If this looks right I'm happy to open a PR updating the example; I may well be missing a context where the documented form still applies.

Start with en/02_Developer_Guides/15_Customising_the_Admin_Interface/01_ModelAdmin.md on branches 5 and 6, then compare its q[FieldName] example with the admin grid request and SearchContext/GridState behavior described in the issue. Confirm the behavior in CMS 5 and CMS 6, and update the example so the documented search field and filter work with the admin grid while preserving any valid URL context.