`isBlocked` does not inherit through parent hierarchy

[teal-bauer]

Summary

core.IsBlocked() only checks direct blocking relationships. If epic A blocks epic B, children of epic B (features, tasks) still show as "ready" — because they have no direct blockers themselves.

Epic A  --blocks-->  Epic B
                       └── Feature X (child of B, shows as ready)

Where

internal/beancore/links.go — FindActiveBlockers() checks:

1. The bean's own blocked_by field
2. Other beans listing this bean in their blocking field

Neither walks up the parent chain.

Affected

Everything that uses isBlocked filtering: list --ready and the GraphQL isBlocked filter. The new workflow commands in #89 (ready, next, blocked) also rely on this.

Open question

Not sure what the design intention is here. Possible interpretations:

1. Children inherit parent's blocked status — if your parent is blocked, you're blocked. Simple, predictable. But maybe too coarse: you might want to prep child tasks while the parent epic is still blocked at the epic level.
2. Children are independent (current behavior) — blocking only applies to the exact beans in the relationship. Users need to explicitly block children too.
3. Middle ground — isBlocked becomes ancestry-aware, but there's a way to distinguish transitive vs direct blocking so callers can choose.

wdyt?

[teal-bauer]

@hmans I don't know if you've had a chance to ponder which solution, if any, you'd prefer here?

[hmans]

Neither of these is perfect, so I would lean towards the most simple one, which would be 1. The API and CLI probably need a way to express towards both the human and the agent that a block is implicit so they don't futilely try to remove the block next.

Would be happy to accept a PR for this!

[teal-bauer]

Isn't that what the other PR does, though? There is a direct isBlocked on parent/child, and a flag that says if something is instead transitively blocked?