Future: per-post-type syndication routing engine

> Stub — flesh out after additional `Connection_Provider`s exist and a routing engine has more than one axis to route along.
>
> Internal tracking: [DOTCOM-16923](https://linear.app/a8c/issue/DOTCOM-16923/future-per-post-type-syndication-routing-engine)

## Context

Today FOSSE syndicates everything to every connected provider. That's the right default for the MVP, but POSSE in practice is more nuanced — different content shapes belong on different networks:

- Photos → Pixelfed + Bluesky, not email.
- Long-form essays → Mastodon (full text) + Bluesky (teaser-thread, already shipped via `Long_Form_Strategy`) + email newsletter.
- Status-format short notes → all networks.
- Replies → only the network being replied to.
- Drafts marked "private fediverse only" → AP only, never atproto.

We already have *one* axis of this: `Long_Form_Strategy` is a per-post-shape projector. A routing engine generalizes that pattern into a matrix:

```
| AP | atproto | email | nostr | ...
post-format=status | ✓ | ✓ | | ✓ |
post-format=image | ✓ | ✓ | | ✓ |
long-form | ✓ | teaser | ✓ | |
post_type=cpt:bookmark | | | | ✓ |
```

Mechanically: a `Routing_Strategy` projector that reads a `fosse_routing_rules` option (or per-post-type meta) and short-circuits each provider's "should this post syndicate?" decision. Same shape as `Object_Type` and `Long_Form_Strategy`, just one layer up.

## Why deferred

- Premature without more than one provider axis to route along — today we have AP + atproto and the only meaningful per-shape distinction (long-form) is already covered.
- Adding a routing UI before more providers exist would design for a matrix that doesn't exist yet.
- Unified post-type selection across AP + Atmosphere is the prerequisite — it normalizes the *which post types federate at all?* question into one place. Routing is the next layer.

## When to flesh this out

When at least one of the following is true:
- A third `Connection_Provider` (Threads / Nostr / email) is in flight or shipped.
- A user asks for per-post-type targeting (e.g. a CMS-heavy partner with multiple custom post types).
- Unified post-type selection is done and the natural next question is *"OK, but I want CPT X on AP only."*

## Out of scope here

- Adding new providers themselves → tracked in #42.
- Per-post manual override UI in the composer (cross-network send status work is adjacent).
- Routing based on draft/visibility state (private posts, password-protected, etc.) — could fold in here or stay separate.

## References

- The existing `Long_Form_Strategy` projector — single-axis precedent for this shape.
- https://www.citationneeded.news/posse/ — framing on selective syndication.
- https://indieweb.org/POSSE — `u-syndication` / per-target advertising.

---

This is intentionally a long-horizon idea — not on our near-term plate, but external interest and contributions are welcome. Discussion happens here; internal Automattic tracking lives in Linear.

Start by reading the existing Long_Form_Strategy projector and the Connection_Provider abstraction to understand the current syndication decision flow. This issue is intentionally deferred: flesh it out only after another provider or unified post-type selection exists, with routing rules and a clear target matrix defined.

Written by the indexing model from the issue text.