FIX: Prevent frontend JS/CSS from loading in CMS admin context

[lerni]

Description

When ElementFormController triggers UserDefinedFormController::init() in the CMS (e.g. via elemental block rendering), frontend resources like jQuery are loaded and overwrite the admin's jQuery with entwine attached, causing a cascade of JS errors ($.entwine is not a function).

Add a LeftAndMain guard to skip frontend Requirements in admin context. CMS-side userforms UI (userforms-cms.js) is unaffected as it loads through getCMSFields() paths.

Steps to reproduce

1. Install dnadesign/silverstripe-elemental-userforms
2. Add an ElementForm block to any page
3. Set block_default_userforms_js: false in config (needed for frontend display rules)
4. Open that page in the CMS admin
5. Observe JS console errors: $.entwine is not a function, tooltip is not a function, etc.

Workaround (without this fix)

Setting block_default_userforms_js: true prevents the issue but also blocks display rules JS on the frontend.

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[GuySartorelli]

If there's an issue for this, can you please link to it? Otherwise please make a new issue and link to that instead. This is part of the PR template and is important because the tools we use to track contributions are good when tracking issues but aren't great for tracking PRs.

Please also check all the boxes in the checklist that apply - the checklist is there so you can make sure the PR is in a good state prior to being reviewed. If you think you shouldn't check a box that's usually an indication that more work is needed.

[lerni]

Root cause was custom code in my project calling ElementalArea::forTemplate() during a CMS request 🙈 Fixed on my end. Sorry for the noiz. Closing since the standard elemental code doesn't trigger this path in CMS context, though the guard could still be useful defensively.