Implement property management section on admin side of Community Portal

[noce-nick]

Summary

Implement the initial Property Management functionality for the admin side of the Community Portal, allowing authorized community administrators to create, view, update, and remove properties within the current community.

Complete any missing backend functionality required to support this behavior, including application service, GraphQL, authorization, persistence, and integration gaps around the existing Property domain implementation.

Requirements

Authorization

Access to admin-side Property Management must be controlled by:

• propertyPermissions.canManageProperties

Users whose EndUserRole grants canManageProperties may access and manage all properties within the current community, regardless of whether they are otherwise considered administrators or members.

Authorization must be enforced at both layers:

• Frontend: Restrict navigation, routes, pages, and available actions to users with canManageProperties.
• Backend: Restrict all Property Management queries, mutations, application service operations, and domain behaviors using the corresponding Property authorization predicate.

The Property aggregate authorization implementation may also prepare the runtime ownership predicate used by:

• propertyPermissions.canEditOwnProperty
• propertyPermissions.isEditingOwnProperty

This ownership-based authorization path is intended for future member-side Property functionality and is not required to authorize access to the admin-side Property Management pages in this task.

Backend

Complete all missing backend functionality required to support Property Management, including:

• Property application service functionality
• GraphQL queries and mutations
• Domain authorization predicates
• Persistence, mapping, and repository integration where required
• Any other missing implementation needed to support the expected behavior

Property deletion must use the existing Property.requestDelete() domain behavior.

The Property aggregate already delegates deletion state through super.isDeleted, allowing the Cellix Mongo repository implementation to persist the deletion as a soft delete.

Frontend

Add a Properties section to the admin side of the Community Portal.

Properties List

The root Properties page should:

• Display all non-deleted properties for the current community in a table.
• Include relevant identifying property information.
• Provide a View action that navigates to the selected property's details page.
• Provide an Add Property action that navigates to the create page.

Create Property

Provide a page that allows an authorized user to create a property within the current community.

Property Details

Provide a page that:

• Loads and displays the selected property.
• Populates the property's editable forms.
• Allows an authorized user to update and save the property.
• Includes a Remove action in the top-right page actions.
• Protects removal with a confirmation prompt.
• Soft deletes the property through the existing domain behavior.

All new pages and UI components must include Storybook coverage for developer verification.

Verification

Extend the ocom-verification test suites with Property scenarios covering:

• Property listing
• Property creation
• Property retrieval
• Property updates
• Property soft deletion
• Access for users with propertyPermissions.canManageProperties
• Rejection of unauthorized Property Management operations

Acceptance Criteria

• Users with propertyPermissions.canManageProperties can access the Properties section for the current community.
• Authorized users can view the list of non-deleted properties.
• Authorized users can create properties.
• Authorized users can view and update existing properties.
• Authorized users can remove properties through a confirmed soft-delete action.
• Deleted properties no longer appear in the default Properties list.
• Frontend navigation, routes, pages, and actions enforce canManageProperties.
• Backend queries, mutations, application services, and domain operations enforce the corresponding Property Management authorization.
• The Property aggregate is prepared for the future ownership-based canEditOwnProperty authorization path where appropriate, without using it to authorize the admin-side pages in this task.
• The ocom-verification test suites assert the expected Property Management behavior and authorization.
• All new pages and UI components include Storybook coverage.
• The implementation follows existing Community Portal, GraphQL, application service, and Cellix domain patterns.