No MDL statement for Guest Access (anonymous users) — anonymous-access apps can't be built unattended

[TOFBuck]

Summary

There is no MDL verb that enables Guest Access (Studio Pro's Anonymous users setting). The
whole project-security write surface is two statements, so any app whose requirements include
"anyone, without signing in, can view X" hits a hard manual step that no amount of MDL can cover.

SHOW PROJECT SECURITY reports Guest Access, so the value is clearly readable in the model —
it just isn't writable.

Repro

mxcli nightly-20260818-55107169 (v0.18.0), darwin/arm64, Mendix 11.12.2 project.

$ ./mxcli -p eShopMendix.mpr -c "SHOW PROJECT SECURITY"
Security Level: Production
Check Security: true
Strict Mode: false
Demo Users Enabled: true
Guest Access: false          # <- readable
Admin User: MxAdmin

$ ./mxcli syntax security project-security
Syntax:
  ALTER PROJECT SECURITY LEVEL OFF|PROTOTYPE|PRODUCTION;
  ALTER PROJECT SECURITY DEMO USERS ON|OFF;
                              # <- no guest-access statement

./mxcli syntax security lists 7 sub-topics — demo-user, entity-access, microflow-access,
module-role, page-access, project-security, user-role — and none of them sets it.
Grepping the entire ./mxcli syntax --json registry for guest/anonymous returns only three
unrelated hits (validation-rule examples about hotel guests).

ALTER SETTINGS doesn't cover it either: DESCRIBE SETTINGS has no guest/anonymous field.

The --mcp Studio Pro bridge doesn't help, because it routes MDL writes to Studio Pro — with no
MDL statement to route, there is nothing for it to execute.

Expected

Something along the lines of:

ALTER PROJECT SECURITY GUEST ACCESS ON|OFF;
ALTER PROJECT SECURITY GUEST ACCESS ON ROLE <UserRole>;   -- the anonymous user role

Symmetric with the existing DEMO USERS ON|OFF, and round-trippable against what
SHOW PROJECT SECURITY already prints.

Why it matters

Anonymous access isn't a niche setting — it's the front door for public-facing apps (storefronts,
portals, public catalogues). In our case it's a literal requirement:

CAT-01: Anyone, without signing in, can view a paged grid of products showing name, price and image

We're rebuilding the ASP.NET reference app eShopOnWeb on Mendix with mxcli driving every model
change. Everything else in the phase automates cleanly — module, entities, associations, demo-data
seeding, the page, entity access rules, page access, locale and constants. This one setting forces
an otherwise fully unattended build to stop and wait for a human to open Studio Pro and click a
checkbox, and it also blocks the follow-on work (the anonymous shopping basket) that depends on an
anonymous session existing at all.

It's also awkward for CI/headless use: the Linux devcontainer where mxcli is designed to run has no
Studio Pro to click in.

To be fair: it is well documented, just not writable

This isn't a documentation gap — the skills corpus covers anonymous users properly, which is what
makes the missing setter stand out:

• system-module.md documents System.User.IsAnonymous and the User_UserRoles association, so
  the anonymous session is a real System.User row you can associate application entities to.
• write-lint-rules.md exposes project_security.enable_guest_access and
  user_role.is_anonymous as readable lint-rule properties.
• assess-quality.md carries an anonymous-permissions audit checklist (SEC004, plus the DIVD
  "anonymous role should have minimal entity access" check).
• manage-security.md mentions it only via project_security() — read-only reporting.

So mxcli models the concept end to end and can read and audit it. The single missing piece is
the write path. If a setter lands, manage-security.md would want a short section alongside the
existing demo-users guidance.