fix(core): resolve TS2308 duplicate exports so @proof/core compiles under TS5

[devYRPauli]

Problem

The @proof/core barrel (packages/doc-core/src/index.ts) re-exports both
src/formats/marks.ts and src/formats/provenance-sidecar.ts with export *.
Both modules export the same three names — createComment,
getUnresolvedComments, and CommentReply — so under TypeScript 5 the barrel
fails to compile:

packages/doc-core/src/index.ts(2,1): error TS2308: Module
'../../../src/formats/marks.js' has already exported a member named
'createComment'. Consider explicitly re-exporting to resolve the ambiguity.

(same error for getUnresolvedComments and CommentReply). The result is that
@proof/core can't be imported from any consumer compiled under modern,
strict TypeScript.

Fix

Replace the export * from provenance-sidecar with explicit named
re-exports of its 21 non-colliding symbols (10 types + 11 values), letting
marks.ts own the three shared names. The marks-based API supersedes the
legacy comment helpers, so marks.ts is the natural owner.

No other public export changes — every previously-exported name remains
exported except the three duplicates, which are still available via marks.

Verification

• Before: tsc --noEmit on a consumer of @proof/core emits the three TS2308
  errors above.
• After: compiles clean; all of provenance-sidecar's non-colliding exports
  remain importable from @proof/core.

Question for maintainers

I let marks win the three colliding names. If you'd prefer
provenance-sidecar to own them instead, I'm happy to flip the direction —
just let me know.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a914e83320

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep sidecar comment creation paired with addComment

For consumers that still use the legacy sidecar helpers from @proof/core, this omission makes createComment resolve to the marks API while addComment/ProvenanceData still come from provenance-sidecar. In the common flow addComment(provenance, createComment(selector, text, author)), TypeScript now rejects the Mark returned by the marks helper, and JavaScript callers would append a mark-shaped object to provenance.comments instead of a sidecar Comment, corrupting the legacy sidecar data. Consider preserving the sidecar helper under a non-colliding export or otherwise keeping the sidecar helper set internally consistent.

Useful? React with 👍 / 👎.

[devYRPauli]

Thanks - that's a fair callout. The two createComment signatures do differ:

• marks.js: createComment(quote, by, text, threadId?, range?, meta?) -> Mark
• provenance-sidecar.ts: createComment(selector, text, author) -> Comment

and with this barrel the bare createComment / getUnresolvedComments / CommentReply names now resolve to the marks API.

Context for the choice: before this PR the barrel did export * from both modules, so those three names collided and TS2308 made @proof/core completely unimportable - no consumer could use the package at all. The goal here is just to make it compile again, and I let marks.js win the bare names since that is the forward (marks-based) API.

The downside is exactly what you flagged: a legacy sidecar caller writing addComment(prov, createComment(selector, text, author)) no longer type-checks through @proof/core. I'd rather not pick the public semantics unilaterally, so two options depending on the intended direction:

1. Keep marks owning the bare names (current PR) and additionally re-export the sidecar helpers under non-colliding aliases (e.g. createComment as createSidecarComment, getUnresolvedComments as getUnresolvedSidecarComments) so legacy consumers still have a path.
2. Flip it so the sidecar helpers keep the bare names and the marks versions get aliased.

Happy to push whichever you prefer - just let me know which name should own createComment and I'll update the PR.

[devYRPauli]

Bumping this one, since it is blocked on a naming decision rather than on code.

As it stands @proof/core does not compile at all under TS5 (TS2308: createComment, getUnresolvedComments, and CommentReply collide between marks.js and provenance-sidecar.ts), so the package is unimportable for every consumer. This PR makes it compile. The only open question is which module owns the bare names:

1. marks keeps them (what the PR does today), and the sidecar helpers get re-exported as createSidecarComment / getUnresolvedSidecarComments so legacy callers still have a path.
2. The sidecar keeps them and the marks versions get aliased instead.

I am happy to push either. If I do not hear a preference in the next week or so, I will go with option 1 and add the aliases, since that keeps existing sidecar callers working while unblocking the build.

[devYRPauli]

Went ahead with option 1 (pushed as 98652fd): marks.js keeps the bare createComment / getUnresolvedComments / CommentReply, and the provenance-sidecar versions are now re-exported under Sidecar-prefixed aliases - createSidecarComment, getUnresolvedSidecarComments, and SidecarCommentReply - so existing sidecar consumers keep a working path instead of silently resolving to the marks API.

This keeps the barrel build fix non-breaking for both call sites and matches the intent that the marks-based API supersedes the legacy comment helpers. Typechecking the barrel plus its import graph is clean (no TS2308, aliases resolve). Happy to flip to option 2 (sidecar owns the bare names, marks aliased) if you'd prefer that ownership instead.

[devYRPauli]

@dshipper when you get a chance, could you take a look at this one? It's a small, self-contained fix for a TS2308 duplicate-export break in the @proof/core barrel that currently makes the package fail to compile for any consumer on TypeScript 5. The only open question is the export-naming choice, which I've resolved in the way that keeps both the marks and legacy sidecar call sites working - happy to adjust if you'd prefer a different split.