[feat] Make the pending-learnings queue the write path for contribute, and surface it #615

Related

Split out of #485 at the maintainer's request: "Making pending-learnings/ the single write path, routing self-mode through the durable queue, and surfacing queue state during pull is a real gap... But it's a separate change from the branch move and shouldn't gate it."

Problem

pending-learnings/ is a durable queue that already sits outside the clone, where a reset --hard cannot reach it. It is the fallback, not the write path, and nothing ever mentions it.

Three concrete gaps, all still true after #485:

1. Single-repo mode can lose a contribution. contribute persists a durable copy only on the independent-clone path. In single-repo mode a rejected push leaves nothing behind: the note exists only in the temporary file the caller passed to --file.

2. A queued learning is invisible. pull discards the result of publishing the queue, and every failure inside it logs at log.debug. No message anywhere in src/ tells a member that learnings are waiting. Someone whose pushes are refused queues notes indefinitely and is told each time that the next pull will retry.

3. Two write paths, two shapes. contribute writes and publishes; the pull-time retry writes and publishes again through a different call. Contributing is not one operation with one failure mode.

Proposal

Make the queue the write path, not the fallback.

• teamai contribute writes the learning to pending-learnings/ and asks one function to publish it. Contribute itself runs no git command.
• A queue entry is dropped only once its content is confirmed on origin. Write learnings/ to a teamai-learnings branch (direct push, no PR) #485 already gives the publisher a result that distinguishes published, already-present, busy and failed, so this is a read of an existing signal.
• Single-repo mode goes through the same queue, which is what closes gap 1. The queue lives under .teamai/ there, gitignored, so it never shows up in the user's own git status.
• The queue is indexed ahead of the published roots, so a contribution is recallable the moment it is written, online or not, and a queued edit of a published learning is the copy recall serves.
• teamai pull reports what it published and warns, with the reason, when anything is still queued.
• teamai doctor carries a check for the queue with an actionable fix. It rides the existing registry, so doctor --json gets it for free.

No new CLI command, and no change to where a learning goes: that is #485's business.

Acceptance

• A rejected push keeps the note in every mode, single-repo included, and teamai recall still finds it.
• The queue entry survives until the content is confirmed on origin, and the next teamai pull publishes it.
• teamai pull says how many learnings are queued and why, when any are stuck.
• teamai doctor reports the queue, and both stay silent when it is empty.
• Contributing while a pull or push holds the partition sync lock leaves the queue for that run instead of racing it on the shared clone.
• kind: http unchanged.

Out of scope

• Where learnings are written (Write learnings/ to a teamai-learnings branch (direct push, no PR) #485)
• teamai push of skills / rules / docs / env / agents
• CI extract-mr --mode write