feat(hub): Config.FossilUserDefault — set per-repo default committer at hub bootstrap

[danmestas]

This was generated by AI during downstream triage.

Feature request: Config.FossilUserDefault for hub.NewHub

Config.BootstrapUser (default "hub") is passed to libfossil.CreateOpts.User, which creates the user record with caps. It does not set the per-repo "default user" — the setting that bare fossil commit reads when --user is not specified.

Workflows that involve opening the hub's on-disk repo with fossil open and committing via bare fossil commit therefore hit:

Cannot figure out who you are!
Consider using the --user command line option, setting your USER environment variable,
or setting a default user with "fossil user default USER".

Today, callers (e.g. sesh) can't fix this without violating their architectural constraint of "no libfossil / fossil-cli calls". The capability needs to be in EdgeSync's hub.Config surface.

Fix shape

Add a new optional field on hub.Config:

// FossilUserDefault sets the per-repo default user (what bare `fossil commit`
// reads when --user is not specified). Empty leaves libfossil's behavior
// unchanged: no default user set; bare commits in external `fossil` CLI
// processes will fail until the user is configured another way.
//
// When non-empty, applied after repo create/open via libfossil's user
// default API. Idempotent — safe to re-run.
FossilUserDefault string

Wire it through openOrCreateRepo (or equivalent) so it runs whether the repo is freshly created or opened from disk.

Alternative considered: extend BootstrapUser semantics

Have BootstrapUser also set the default user (currently it only creates the record). Cleaner — one config field instead of two — but changes existing behavior for current callers. The additive option above is safer.

Why low priority

This is filed as belt-and-suspenders. The immediate downstream concern (sesh's worker-commit story) is being resolved by the documented worker pattern always being clone-push, where the worker's clone needs its own default user set in the bootstrap script. Source-side default user only matters if:

• A future workflow re-introduces direct on-disk access to the hub repo (path-3 scenarios), or
• Clones inherit the source's default-user setting and we want to push the configuration upstream of every clone

Either way, exposing the capability now means future callers don't have to file a fresh issue or write around the gap.

Acceptance criteria

• Config.FossilUserDefault string field exists with the documented semantics.
• Setting it on a fresh repo + re-opening returns a repo whose libfossil user-default config is the configured value.
• Re-running NewHub with the same FossilUserDefault is idempotent.
• Re-running with a different non-empty FossilUserDefault overwrites (or errors — caller's choice; document it).
• Empty preserves prior behavior — no regression.
• Test: spawn a hub with FossilUserDefault: "test-user", open the repo at the path with libfossil's API, assert the default-user config field reflects the value.

Cross-refs

• sesh up: workers can't commit — no default fossil user seeded in session-repo checkouts sesh#40 — the original report; being closed wontfix-in-sesh since the worker bootstrap is the actual fix point under the clone-push architecture.
• Cross-session fossil sync silent — raw fossil commit in checkouts never triggers fossil.<project-code>.sync sesh#41 — the architectural decision (workers always clone-push; sesh makes no fossil calls).