gate record --round refuses flat entities unconditionally, so a default-shape workflow can open gates whose rounds can never be recorded

[iamcxa]

spacedock gate record --round hard-requires a folder-form entity:

gate record --round requires folder-form entity <slug>/index.md because review artifacts
accumulate beside the entity; convert with `git mv <slug>.md <slug>/index.md` AND rewrite
every `room-ref: ./<slug>/` to `room-ref: ./` in the same commit

Observed on 0.27.0-pre8. The check is still unconditional on main at bcaa4e0b —
internal/gates/operation.go, in the --round branch:

if filepath.Base(entityPath) != "index.md" {
    return Summary{}, fmt.Errorf("gate record --round requires folder-form entity ...")
}

The asymmetry

gate prepare tolerates flat entities. Since #745 it refuses a new flat companion room only when
the workflow declares entity-form: folder — internal/gates/prepare.go, refuseNewFlatCompanion
— and that function's own comment says a workflow declaring nothing "accepts either shape: that is
every workflow today, and flat is still what filing mints by default".

gate record --round applies no such condition. So a workflow that files flat entities, which is
the default, can prepare gates, present them, and close them with revise, and then cannot record
a single round against any of them.

Impact

skills/feedback-rejection-flow makes the round record step 2 of five, with an explicit hold: if
the recorder refuses, do not claim the round was recorded, do not re-run the reviewer, and do not
prepare the next gate. Read literally that halts every rejection cycle in a flat workflow. Read
pragmatically, the first officer records the round elsewhere and the neutral room stays empty —
which is what happened here: three correction rounds on one entity, none of them recordable, the
supersession bookkeeping carried in the entity body instead.

The refusal is also the first signal a flat workflow gets that the recorder was never available to
it. Nothing at commission time, at filing time, or at gate prepare says so, and a workflow only
finds out at its first rejection — which is exactly when it is least convenient.

A second observation, offered as an observation

Even setting the entity form aside, a room produced by gate prepare does not contain the pair
--round asks for. The prepared room here held gate-briefing.json and request.json, while
--round requires --briefing .../briefing.json and --log .../briefing.review.jsonl
(internal/gates/io.go). From outside I cannot tell whether that pair is meant to come from a
reviewer harness rather than from gate prepare, so this is what was seen rather than a claim
about intent. It does mean the remedy the error message prescribes — convert to folder form —
would not by itself make the command runnable in this configuration.

Expected

Any one of:

• --round applies the same condition gate prepare does, so flat workflows either both work or
  both refuse, instead of diverging at the rejection path;
• or the incompatibility surfaces earlier — at commission, or at the first gate prepare — so a
  workflow learns its rounds are unrecordable before it has rounds to record;
• or the round room is written in a shape a flat entity can hold.

Adjacent: #221 (folder form for feedback-cycle entities), #739 / #745 (the conversion bug the
current message's remedy walks toward).