Pre-submission embargo negotiation is documented as permitted but has no implemented mechanics

[sei-ahouseholder]

Concern

The documentation states that embargo negotiation MAY begin before a report is
sent, but there are no implemented mechanics for it. Every embargo path in the
codebase is case-scoped, and pre-report there is no case and no participant for
that state to live on.

Evidence

docs/topics/process_models/model_interactions/rm_em.md (§ "Start Embargo
Negotiations As Early as Possible") states:

The EM process MAY begin (i.e., the initial propose transition
q^em ∈ N → P) prior to the report being sent to a potential Participant
(q^rm ∈ S)

and motivates it:

Beginning an embargo negotiation before providing a report can be useful in
cases where a Participant wishes to ensure acceptable embargo terms prior to
sharing a report with a potential recipient.

Against that, the implementation:

• EmbargoLifecycle.propose_embargo()
  (vultron/core/services/embargo_lifecycle.py) requires a case_id.
• PEC state lives on a CaseParticipant (ParticipantStatus.consent), and a
  CaseParticipant exists only within a case.
• InviteToEmbargoOnCasePattern requires context_=VULNERABILITY_CASE, so even
  the wire format presumes a case.

Pre-report, none of those exist. The documented behaviour has nowhere to be
recorded.

Why it matters

This is a real CVD pattern — a finder who wants embargo terms agreed before
handing over vulnerability details — and it is exactly the scenario where the
protocol's value is highest. It is currently documented as permitted, which means
an implementer reading the docs will believe it is supported.

Note this is independent of #2066 / ADR-0059: RSVP deadlines apply to
case-scoped embargo invitations. If pre-case negotiation is ever built, it will
need its own answer for how a deadline attaches to an invitation with no case.

Questions to resolve

• Is the documented MAY a commitment, or should the docs be corrected to
  scope it as future work? (A docs correction is a legitimate resolution.)
• If it is a commitment: where does pre-case embargo negotiation state live?
  Candidate shapes include a proto-case, a standalone negotiation object, or a
  CaseProposal extension (ADR-0023).
• How does pre-report negotiated state migrate into the case once the report
  is submitted and the CaseActor initialises the case (ADR-0041)?
• Does the wire format need a non-case-scoped embargo negotiation context?
• Does this interact with the default-embargo path (EP-04, notes/embargo-default-semantics.md),
  which currently produces EM.ACTIVE at case creation?

References

• docs/topics/process_models/model_interactions/rm_em.md
• Surfaced while planning Embargo offers (invites) should support optional expiration deadlines via Offer.end_time #2066 (docs PR: docs: plan issue #2066 — embargo invite RSVP deadlines #2210)
• notes/participant-embargo-consent.md § "Open Questions"
• ADR-0023 (CaseProposal), ADR-0041 (CaseActor-authoritative case init)

[sei-ahouseholder]

Routed onto epic #1935 (Protocol authority & lifecycle semantics) rather than #2088 (Protocol vocabulary extension) or #2100 (Draft protocol spec).

Rationale: this is an undesigned protocol-semantics question — where does pre-case embargo negotiation state live, and is the documented MAY a commitment — not a message-catalog/field addition and not document readiness. #2100's scope statement explicitly excludes it ("covers document readiness, not protocol design gaps... substantive protocol questions... tracked separately under #1935 and #2088"). #1935 already carries a related PEC item (#1871).

⚠️ Schedule tier not inherited from #1935 — the available token lacks Project #24 access (FORBIDDEN on organization.projectV2), so this issue is not on the board at all yet and needs manual placement.