feat(core): add Forbid create object and Forbid edit object space permissions

[MichaelUray]

Fixes #9079

Problem and change

Space type roles could only forbid deleting objects. Add two more space-scoped
forbid permissions, 'Forbid create object' (TxCreateDoc) and 'Forbid edit object'
(TxUpdateDoc, which also covers mixin attribute updates), and offer them in all
space types that already offer 'Forbid delete object'.

They are enforced server-side by SpacePermissionsMiddleware like the existing
forbid permission and apply to all objects inside the space, including
comments and attachments. Two adjustments in the middleware:

• these generic create/update forbids are not applied to the space document
  itself, so role holders can still manage members, role assignments and
  archiving of the space;
• when several matching permissions without txMatch apply, a forbidding one
  now wins instead of depending on the role/permission order.

On the client, canCreateObject and canChangeDoc (used by inline attribute
editors, drive and card) honour the new permissions.

Tests

New unit tests foundations/server/packages/middleware/src/tests/spacePermissions.test.ts. Checked manually on a self-hosted instance: with a role holding "Forbid create object" and "Forbid edit object", the server rejects creating an issue and editing its title for a member with that role; the space owner can still create/edit and manage members and roles.

Notes

• Enforcement is server-side. Many create/edit controls (e.g. inline list editors, the New issue button) do not consult these permissions yet, so they stay visible and the server rejects the change; hiding them everywhere is a follow-up across plugins.
• The two new permissions do not apply to the space document itself, so role holders cannot lock themselves out of space management.