Rename a tier's capacity to quota, because it is not a capacity

The danger is calling something a capacity when it is not one. A capacity is how many a space holds. A tier's capacity is nothing of the kind: it is a selling limit that may be any number at all, and naming it capacity invites every reader to treat it as a fact about the room.

That cost a whole debugging session. A booking page showed "825 left" for one tariff while the hall had 813 places of that grade, and nothing was broken: 825 was a typed selling limit, the physical count was elsewhere, and the page prints whichever is lower. Two different numbers, one word.

What changes

• yoyaku_slot_category.capacity becomes quota, and getCapacity() becomes getQuota().
• yoyaku_category.default_capacity becomes default_quota, and getDefaultCapacity() becomes getDefaultQuota().
• Column names change with them. No update hook and no compatibility shim: the module is pre-1.0, so reinstall is the upgrade path.

Three other fields keep the word, because for them it is correct: a slot's overall capacity, a resource's default capacity, and a pooled area's capacity. With no venue attached, a resource or slot capacity is the room itself, a dorm of twelve beds or a refuge of thirty places. With a venue, the places are the count and it acts as a cap over them. Either way it describes space, never an allocation, which is the line this draws.

The hazard, and how to avoid it

Three fields use the identical literal capacity and the identical method getCapacity(), so no search and replace is safe. BookingManager has a line carrying both concepts at once, which is the clearest illustration of why this is worth doing: after the rename one side reads getQuota() and the other getCapacity().

The work is about 99 edits, roughly 22 in production code and 75 in tests, and each occurrence has to be classified by the entity it belongs to before being touched. The pooled payload's own capacity array key stays, since one of its uses is a JSON key the browser reads.

Nothing in YAML, views, config schema or the venue-package importer names either field, so there are no config keys to migrate. The remaining key-like occurrences are PHP array keys derived from the field name: two table headers, two controllers and the form-widget map.

Also worth saying out loud

While in the area: a pooled area's capacity replaces its drawn places rather than capping them, so declaring one takes the seats out of individual sale. That is right for an area whose seats have been removed and wrong if they are still in, and nothing in the UI says so today.