POST /api/rooms silently ignores groupId

[Rikdekker]

Steps to reproduce

1. POST /apps/roomvox/api/rooms with a body that includes groupId:

{ "name": "Boardroom", "groupId": "building-a" }

2. Read the created room back with GET /apps/roomvox/api/rooms/{id}.

Expected behaviour

The room belongs to room group building-a.

Actual behaviour

groupId is null. The value is silently dropped — no error, no warning.

Cause

RoomApiController::create() builds the $data array from an explicit list of
request parameters, and groupId is not among them:

https://github.com/nextcloud/RoomVox/blob/main/lib/Controller/RoomApiController.php#L225-L240

The service layer is ready for it — RoomService::createRoom() reads
$data['groupId'] ?? null (lib/Service/RoomService.php:142) — so the value is
lost in the controller before it ever gets there.

PUT /api/rooms/{id} does handle it: groupId is in $updatableFields
(RoomApiController.php:295) and is also in $nullableFields (:297), so an
update can both set and clear it.

Suggested fix

Add one line to the $data array in create():

'groupId' => $this->request->getParam('groupId', null),

Worth checking while in there: create() and update() maintain two separate
field lists that have drifted apart. active and exchangeConfig are updatable
but not settable on create either — which may well be intentional, unlike
groupId.

Workaround

Create the room first, then assign the group with PUT /api/rooms/{id}.

Impact

API and CSV-import consumers only. The admin interface is unaffected: it creates
the room and then assigns the group in a separate call, which is why this went
unnoticed.

Notes

Found while auditing docs/architecture/api-reference.md against the code. The
documentation listed groupId as a create parameter. Rather than silently
correcting the docs to match the bug, the current behaviour is now documented
with a pointer to the workaround, so the doc stays honest until this is fixed.